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The  thesis  addresses  the  design  of  multiple-server  implementations  for  services 
in  distributed  systems — a  generalization  of  the  replication  management  problem. 
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of  a  service  not  be  able  to  distinguish  a  single-server  implementation  from  one 
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obligations  can  be  used  to  show  that  the  one  implements  the  other. 

Finally,  a  methodology  for  designing  a  multiple-server  implementation  of  a 
service  is  presented.  The  methodology  is  based  on  structural  refinement  and  on 
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Introduction 


Programs  for  distributed  systems  are  often  structured  in  terms  of  clients  and 
services.  A  service  supports  some  data  abstraction,  which  consists  of  data  objects 
and  operations  to  manipulate  them.  Clients  of  the  service  are  processes  that  use 
this  abstraction.  A  service-interface  defines  the  data  abstraction,  and  a  service- 
implementation  is  a  realization  of  the  abstraction.  For  example,  the  program  in 
Figure  1.1  consists  of  two  services,  tickets  and  guard,  and  clients  ci, . . . ,  c„.  The 
tickets  service  provides  the  abstraction  of  a  ticket  dispenser,  supporting  a  single 
operation  getTicket.  The  guard  service  provides  the  abstraction  of  an  access 
guard,  supporting  the  operations  enter  and  exit.  By  invoking  getTicket ,  a  client 
acquires  a  unique  ticket;  by  invoking  enter  with  this  ticket,  exclusive  access  to 
the  critical  section  is  ensured. 

Partitioning  a  service  into  a  service-interface  and  a  service-implementation 
allows  clients  to  ignore  implementation  details  of  the  service  and  allows  the 
service-implementation  to  ignore  implementation  details  of  the  clients.  How¬ 
ever,  knowledge  of  how  clients  use  a  service  often  can  be  exploited  in  designing 
a  service-implementation  that  is  tailored  to  an  application.  For  example,  for  the 
system  of  Figure  1.1,  the  fact  that  exit  is  invoked  only  by  a  client  having  access 
to  the  critical  section  simplifies  the  service-implementation — there  is  no  need  to 
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service  tickets 
interface: 

type:  ticket ; 
operation: 

getTicket(x ar  t  :  ticket ); 
implementation  . . . 
end  of  service  tickets 

service  guard 
interface: 

operation: 

enter(t :  ticket)  returns  boolean, 
ex  it(); 

implementation  . . . 
end  of  service  guard 

cobegin  ||i<p<n 
Cy\  var  tktp  of  ticket ; 
do  true  — * 

NCSj, 

getp:  getTicket(tktp)-, 
entcrp:  do  -<enter(tktp)  — ►  skip  od; 

CSP 

exitp :  exit()\ 

od 

coend 


Figure  1.1:  A  client /service  program. 


communication 

channel 


Figure  1.2:  A  single-server  implementation, 
test  for  spurious  invocations,  and  concurrent  invocations  of  exit  never  happen. 

1.1  Implementing  Services 

A  service  is  typically  implemented  by  servers,  which  are  processes  that  might  re¬ 
side  anywhere  in  the  distributed  system,  and  by  client  stubs,  which  are  programs 
that  reside  on  computers  executing  clients.  A  server  maintains  state  information 
pertaining  to  the  implementation  of  the  service.  It  receives  requests  to  update 
or  read  that  state  and  responds  by  sending  replies.  A  client  stub  translates  in¬ 
vocations  of  service  operations  into  requests  to  one  or  more  servers,  sends  these 
requests  to  the  servers,  receives  the  replies,  and  uses  these  replies  to  compute 
result  value,  which  is  returned  to  the  client.  For  example,  a  server  for  the  tickets 
servioe  «6  Figure  1.1  might  maintain  a  variable  g  to  store  the  value  of  the  most 
rrrmtfr  Jlspmnrrl  ticket  and  might  support  requests  to  increment  g  and  to  read 
its  valne.  A  client  stub  would  issue  such  requests  in  implementing  getTicket. 

A  service  implementation  that  is  based  on  a  single  server  is  structured  as  in 
Figure  1.2.  Such  an  implementation  is  usually  quite  simple.  However,  it  can  have 
drawbacks.  First,  the  service  cam  only  be  as  reliable  as  the  computer  that  hosts 
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channel 

Figure  1.3:  A  multiple- server  implementation. 

the  (single)  server.1  Failure  of  the  server’s  computer  halts  the  service.  Second, 
having  only  a  single  server  might  lead  to  poor  performance.  For  example,  the 
computer  executing  the  (single)  server  might  not  be  able  to  handle  requests  in  a 
timely  manner,  or,  due  to  distance,  some  clients  might  only  have  a  narrow  band¬ 
width  communication  channel  to  the  server’s  computer.  Finally,  organizational 
constraints  might  dictate  that  data  maintained  by  the  service  reside  at  different 
sites,  say  for  reasons  of  privacy  or  security.  This  would  prevent  any  single  site 
from  hosting  the  server. 

The  problems  associated  with  a  single-server  implementation  can  be  circum¬ 
vented  by  employing  several  servers  to  implement  a  service  (see  Figure  1.3). 
With  multiple  servers,  failure  of  a  computer  that  hosts  a  server  can  be  masked. 
Performance  problems  can  be  avoided  by  using  multiple  servers  and  designing 
client  stubs  to  forward  requests  to  a  server  that  is  nearby;  servers  must  update 
each  other  periodically  [LL86].  Finally,  organizational  constraints  can  be  ad¬ 
dressed  with  multiple  servers  by  assigning  different  servers  to  different  parts  of 
the  organization. 

Unfortunately,  designing  multiple-server  implementations  can  be  difficult. 
When  several  servers  are  used  to  implement  a  service,  server  activities  might 


lWe  assume  clients  do  not  fail. 
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have  to  be  coordinated.  For  example,  in  a  multiple- server  implementation  of 
the  guard  service  of  Figure  1.1,  servers  must  be  coordinated  so  that  they  do  not 
concurrently  grant  different  clients  access  to  the  critical  section. 

The  state  machine  approach  [Lam78,Sch86]  is  one  of  the  more  general  meth¬ 
ods  for  designing  multiple-server  implementations.  Given  a  single-server  imple¬ 
mentation  of  a  service,  this  approach  permits  derivation  of  a  multiple-server 
implementation  that,  as  far  as  clients  can  tell,  behaves  exactly  like  the  single¬ 
server  one.  This  is  done  by  starting  all  the  servers  in  the  same  initial  state,  using 
protocols  to  guarantee  that  every  non-faulty  server  (i.e.,  server  that  runs  on  a 
non-faulty  machine)  behaves  like  the  single  server  of  the  corresponding  single¬ 
server  implementation,  and  by  requiring  that  client-stubs  generate  a  result  value 
using  a  reply  from  a  non-faulty  server. 

The  state  machine  approach  exploits  an  assumption  that  the  behavior  of  each 
server  is  completely  determined  by  its  initial  state  and  the  sequence  of  requests 
it  processes.  It  is  based  on  the  following  rules  for  processing  requests: 

Input  agreement:  All  non-faulty  servers  receive  every  request. 

Input  order:  All  non-faulty  servers  process  requests  in  the  same  order. 

Output  select:  A  client-stub  generates  a  result  value  using  a  reply  from  a  non- 
faulty  server. 

Input  agreement,  Input  order,  the  requirement  that  all  servers  start  with  the 
same  initial  state,  and  the  assumption  that  a  server’s  behavior  is  deterministic, 
together  guarantee  that  the  states  of  sill  servers  are  identical  after  processing 
the  *th  request.  Moreover,  these  server  states  will  all  be  equal  to  the  state  of 
the  single  server  of  the  corresponding  single-server  implementation.  This  is  the 
reason  that  Output  select  permits  a  result  value  to  be  generated  from  the  reply 
of  any  non-faulty  server — any  such  reply  is  necessarily  identical  to  the  reply  the 
corresponding  single-server  would  have  sent. 
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The  state  machine  approach  allows  a  multiple-server  implementation  to  be 
derived  mechanically  from  a  single-server  one.  However,  this  multiple-server 
implementation  may  exhibit  poor  performance.  This  is  because  to  guarantee 
that  the  sequences  of  requests  processed  by  each  server  are  identical,  requests 
are  tagged  with  unique  identifiers  from  some  total  order  (such  as  unique  time- 
stamps),  and  servers  process  requests  in  that  total  order.  If  a  request  arrives  at 
a  server  out  of  order,  then  the  server  must  delay  processing  that  request  until  it 
receives  and  processes  all  preceding  requests.  Thus,  the  state  machine  approach 
may  cause  requests  that  could  be  processed  to  be  delayed. 

A  more  fundamental  problem  with  the  state  machine  approach  is  that  trade¬ 
offs  between  Input  agreement,  Input  order,  and  Output  select  are  not  supported, 
although  they  are  sometimes  possible.  Schemes  where  for  each  service  operation,’ 
a  stub  requests  that  only  a  majority  of  the  servers  do  the  operation  violate  Input 
agreement,  yet  they  are  sometimes  sufficient.  For  example,  in  an  update  opera¬ 
tion,  only  a  majority  of  servers  need  be  changed  provided  that  in  read  operations, 
replies  from  majority  of  servers  are  collected  and  one  with  the  most  recent  in¬ 
formation  (according  to  some  version  identification  scheme)  is  selected  [Gif79, 
Tho79].  Thus,  a  weaker  (and  cheaper)  Input  agreement  rule  might  be  sufficient 
provided  a  stronger  (and  more  expensive)  Output  select  rule  is  used.  Similarly, 
tradeoffs  between  Input  order  and  Output  select  are  sometime  possible.  Finally, 
if  operations  commute,  then  processing  them  in  different  orders  will  not  generate 
different  states;  for  such  services  Input  order  is  too  strong  a  requirement. 

1.2  Implementations  from  Refinement 
Mappings 

This  thesis  describes  a  methodology  for  designing  multiple-server  implementa¬ 
tions  given  single-server  implementations.  The  methodology  is  general  enough 
to  support  trade-offs  like  the  ones  between  Input  agreement,  Input  order,  and 


Cj,:  do  true  — + 

NCSp 

getp :  getT  icket{tktp ); 
enterp :  do  tfctp  ^  nit  — ►  skip  od; 

CSP 

exitp.  nxt  :=  nit  +  1; 

od 

Figure  1.4:  Client  Cp  with  an  in-line  expansion  of  an  implementation  of  the  guard 
service. 

Output  select  described  above,  but  retains  the  simplicity  of  the  state  machine  ap¬ 
proach.  In  addition,  the  methodology  supports  design  of  service-implementations 
particularly  well-suited  for  specific  applications. 

The  key  to  our  methodology  is  viewing  a  single-server  implementation  as  a 
specification  of  a  service,  and  regarding  a  multiple-server  implementation  to  be 
correct  if  and  only  if  it  implements  that  specification.  The  methodology  is  based 
on  defining  a  mapping  that  allows  states  of  a  multiple-server  implementation 
to  be  regarded  as  states  of  a  single-server  one,  and  on  showing  that  under  this 
mapping  the  multiple-server  implementation  can  be  viewed  as  the  single-server 
implementation.  Having  states  of  different  servers  be  identical  after  processing 
the  ith  request,  as  required  by  the  state  machine  approach,  is  only  one  mapping 
between  states  of  a  multiple- server  implementation  and  states  of  a  single-server 
one.  Other  mappings,  when  possible,  lead  to  other  implementations. 

To  illustrate  the  methodology,  suppose  a  multiple- server  implementation  of 
the  guard  service  of  Figure  1.1  is  desired,  and  we  are  given  the  single- server  imple¬ 
mentation  described  by  enter p  and  exitp  of  Figure  1.4.  In  that  implementation, 
a  variable  nit  indicates  the  value  of  the  ticket  held  by  the  process  granted  access 
to  the  critical  section.  The  server  provides  an  operation  read  and  an  operation 
increment  to  access  and  modify  nit.  Thus,  in  response  to  an  invocation  of  enter, 
the  stub  requests  read  from  the  server,  waits  for  the  reply,  compares  the  reply 
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Cj,:  do  true  — ► 

NCSp 

getp :  getTicket(tktp); 
enterp :  do  ^  — +  skip  od; 

CSp 

txitp.  (cobegin  ||i<,<* 

nxtj  :=  nxtj  -(- 1; 
coend) 
od 

Figure  1.5:  A  refinement  of  Figure  1.4. 

value  with  the  ticket  value  supplied  by  the  client,  and  returns  the  comparison 
result  to  the  client.  In  response  to  exit,  the  client  stub  requests  increment. 

Given  this  single-server  implementation,  we  can  obtain  a  multiple- server  im* 
plementation  as  follows.  Suppose  n  servers  are  desired,  where  the  jth  server 
maintains  variable  nxtj.  Define  a  mapping  that  gives  a  value  to  nxt  in  terms  of 
nxt\, . . . ,  nxtn: 

* 

nxt  i  if  true 

nxt  =  ■ .  (1.1) 

nxtn  if  true 

Observe  that  mapping  (1.1)  is  well-defined  only  if 

nxt i  =  nxt2  =  ...=.  nxtn  (1.2) 

holds  cm  any  state.  So,  (1.1)  is  a  function  only  if  (1.2)  holds.  Consequently, 
provided  (1.2)  holds,  (1.1)  allows  us  to  regard  the  state  of  a  multiple-server 
implementation  as  being  a  state  of  the  single-server  one. 

It  is  straightforward  to  ensure  that  (1.2)  holds  initially.  In  order  to  ensure 
that  (1.2)  continues  to  hold,  we  must  guarantee  that  whenever  the  state  of  one 
server  is  changed,  then  so  are  the  states  of  all  others.  An  implementation  where 
this  is  done  appears  in  Figure  1.5.  Note  that  the  only  changes  to  Figure  1.4 
are  in  enter p  and  exitp,  which  now  access  variables  nxt\, . . .  ,nxtn  instead  of 
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nxt.  In  enterp  the  stub  requests  that  the  local  server  (which  maintains  nxtp) 
perform  a  read,  and  in  exitp  the  stub  atomically  requests  that  all  servers  perform 
an  increment — an  action  necessary  to  maintain  (1.2).  From  the  point  of  view 
of  performance,  mapping  (1.1)  provides  an  inexpensive  read  operation,  but,  to 
maintain  (1-2)  expensive  updates  are  necessary. 

Note  that  the  multiple-server  implementation  presented  in  Figure  1.5,  is,  in 
fact,  a  state-machine  style  solution.  However,  we  derived  this  implementation 
not  by  the  rules  of  the  state  machine  approach,  but  from  a  mapping.  Another 
mapping,  might  have  led  to  a  different  implementation. 

1.2.1  Hiding  Details 

In  the  examples  above,  we  have  abstracted  details  concerning  communication 
between  stub  and  server.  For  example,  the  action  nxt  :=  nxt  +  1  abstracts  an 
interleaving  of  stub  actions 

sendT  oS  erver  (  “increment”  ) ; 
receiveFromServer( ); 

and  server  actions 

receiveFromStub(commandy, 

if  command  =  “increment”  — *  nxt  :=  nxt  -f  1; 

Q  command  =  “read”  — ►  sendT oStub(nxty 

ft 

Also,  the  construct  (...)  in  action  exitp  of  Figure  1.5  implies  that  all  update 
requests  that  originate  from  a  single  exit  invocation  of  client  p,  are  performed  in 
the  same  order  by  every  server.  To  use  another  term  from  the  literature,  action 
exitp  specifies  an  atomic  broadcast  of  the  requests  to  update  the  nxtj' s. 

Using  assignment  statements  to  model  interleaving  of  requests,  replies,  and 
server  internal  operations,  and  using  a  cobegin  statement  to  model  multicasting, 
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is  just  a  consequence  of  the  level  of  abstraction  we  chose  for  our  programs.  Our 
methodology  is  not  limited  to  this  level  of  abstraction;  a  designer  should  choose 
abstractions  that  are  proper  for  the  problem  at  hand.  The  difficulty  of  designing 
multiple-server  implementations  of  a  service,  however,  is  mainly  in  designing  a 
single-server  implementation  and  in  choosing  a  good  mapping.  Details  of  the 
communication  are  usually  secondary.  Choosing  the  right  level  of  abstraction — 
one  that  reveals  enough  details  so  that  the  solution  is  not  trivial,  and  hides  just 
enough  so  that  the  solution  is  elegant — remains  an  art. 

1.3  Organization  of  Thesis 

Chapter  2  defines  specifications  and  the  notion  of  implementing  a  specification. 
Chapter  3  shows  how  proof  outlines  can  be  viewed  as  specifications  and  gives 
a  theoretical  foundation  for  a  methodology  of  deriving  multiple-server  imple¬ 
mentations  from  single-server  implementations.  In  Chapter  4  we  describe  the 
methodology  and  illustrate  it  by  examples.  We  conclude  in  Chapter  5  by  relat¬ 
ing  our  approach  to  the  existing  research.  We  also  outline  directions  for  applying 
and  extending  this  work. 


{ 


Chapter  2 

Specifications  and 
Implementations 


In  chapter  1,  we  suggested  that  a  multiple- server  implementation  of  a  service  can 
be  viewed  as  an  implementation  of  a  specification  given  by  some  other — perhaps 
single-server — implementation.  In  this  chapter,  precise  definitions  of  specification 
and  implementation  are  given.  The  material  is  based  on  [Lam83,Lam89]. 

2.1  Specifications 

A  specification  characterizes  expected  behavior  of  a  system.  To  specify  a  sys¬ 
tem  that  comprises  a  single  process,  input/output  relations,  which  relate  values 
of  variables  at  termination  to  their  initial  values,  often  suffice.  For  a  system  of 
concurrent  processes,  other  properties,  involving  intermediate  states  of  the  com¬ 
putation,  can  be  of  interest.  In  fact,  the  program  state  at  termination  might  be 
wholly  irrelevant  for  a  concurrent  program,  because  many  such  programs  are  not 
intended  to  terminate.  Thus,  a  specification  of  a  concurrent  system  must  define 
a  set  of  sequences  of  states  rather  than  simply  a  set  of  pairs  of  states. 

Many  different  languages  exist  for  expressing  specifications.  There  are  spe¬ 
cially  designed  specification  languages  such  as  Larch  [GHW85]  and  Z  [Spi89], 
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terse  mathematical  notations,  such  as  Temporal  Logic  [MP81],  and  graphical  no¬ 
tations  such  as  state-transition  diagrams  [HPSS87].  Programming  languages  can 
also  serve  as  specification  languages,  since  a  program  defines  a  set  of  sequences  of 
states — those  sequences  that  correspond  to  executions  of  the  program.  Indepen¬ 
dent  of  the  language  in  use,  the  meaning  of  a  specification  of  a  concurrent  system 
5  can  be  described  in  terms  of  a  triple  (Es,As,Bs),  where  E s  is  a  set  of  states , 
As  is  a  set  of  actions,  and  Bs  is  a  set  of  sequences  of  states  called  behaviors. 

2.1.1  States 

States  are  functions  that  map  variable  names  to  values.  We  use  s(v)  to  denote 
the  value  of  a  variable  v  in  a  state  s.  The  domain  of  every  state  in  E$  is  the  set 
1V(S);  the  range  of  every  state  is  the  union  of  the  types  of  the  variables  in  N(S). 
For  any  variable  v  6  iV(5),  if  v  is  of  type  Tv  then  s(v)  €  Tv  holds  for  any  state  s 
because,  a  state  always  maps  a  variable  name  to  a  value  in  that  variable’s  type. 
For  convenience,  we  define  s(E)  for  an  expression  E,  to  be  the  value  of  E  after 
every  free  variable  v  in  E  has  been  replaced  by  s(v). 

Control  variables  are  used  in  order  to  specify  aspects  of  the  state  that  restrict 
possible  transitions  of  control.  We  associate  with  every  action  a  unique  pair 
of  distinct  control  points :  an  entry  control  point,  and  an  ex it  control  point. 
Before  an  action  can  be  executed,  its  entry  control  point  must  be  active ;  when 
it  terminates,  its  exit  control  point  becomes  active.  We  assume  that  for  every 
action  a  6  As,  Af(S)  includes  two  Boolean  control  variables.  The  first,  at(a),  is 
assigned  the  value  true  by  any  state  for  which  the  entry  control-point  of  action 
a  is  active,  and  false  by  any  other  state;  the  second  control  variable,  after(a),  is 
assigned  true  by  any  state  for  which  the  exit  control-point  is  active,  and  false  by 
any  other  state. 

Not  all  functions  with  domain  N(S)  represent  meaningful  assignments  of  val¬ 
ues  to  variables.  For  example,  it  is  reasonable  to  assume  that  the  entry  and  exit 
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control  points  of  an  action  a  are  never  simultaneously  active.  Thus,  a  function 
that  assigned  true  to  both  at(a )  and  after(a)  would  not  be  meaningful  as  a  state. 
To  exclude  from  £5  such  meaningless  functions,  we  specify  constraints — Boolean 
expressions  over  N(S).  Only  functions  that  satisfy  these  constraints  are  included 
in  £5.  Thus,  if  x,y,  z  are  in  N(S)  and  x  <  y  +  z  is  a  constraint,  then,  for  every 
5  6  £5,  the  expression  s(x)  <  s(y)  +  s(z)  must  evaluate  to  true. 

For  convenience,  we  distinguish  constraints  of  the  form  x  =  E,  where  x  is 
a  variable  and  E  is  an  expression  involving  variables.  We  call  such  constraints 
definitions  because  they  define  the  value  that  a  state  will  assign  to  x  in  terms 
of  the  values  assigned  by  that  state  to  the  variables  in  E.  Variables  that  appear 
only  on  the  right-hand  side  of  definitions  are  considered  primitive.  Variables  that 
appear  on  the  left-hand  side  of  a  definition  are  considered  derived,  as  their  value 
is  a  function  of  the  value  assignment  to  the  primitives.  One  case  where  derived 
control  variables  are  handy  is  in  arguing  about  execution  of  non- atomic  actions. 
This  is  illustrated  in  Section  2.3. 

2.1.2  Actions 

An  action  is  the  basic  unit  of  execution  and  changes  the  state  indivisibly.  Possible 
state  changes  of  an  action  a  G  As  define  a  relation  C  £5  x  £5  such  that 
(s,  t)  €  'R-a  holds  iff 

•  it  is  possible  to  execute  a  in  state  s,  and 

•  executing  a  on  s  may  result  in  state  t. 

An  action  a  €  As  can  be  specified  by  a  predicate  Pa5  that  characterizes  Tlf . 
The  free  variables  in  Pf  are  from  JV(S)  and  a  primed  copy  of  N(S),  denoted 
N'(S).  A  pair  of  states  (s,s')  satisfies  P/,  denoted  (s,s')  Pas,  iff  the  Boolean 
expression  that  results  from  replacing  the  free  variables  from  N(S)  by  their  values 
in  s  and  replacing  the  free  variables  from  N'(S)  by  their  values  in  s' ,  evaluates 
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to  true.  Thus,  a  primed  variable  in  P/  refers  to  the  value  of  that  variable  after 
the  execution  of  a.  The  relation  is  defined  as 

nl  =  ((),V)€SsxEs|«),.,)|=i^)A 

((*  6  j V(S)  A  x  * /r«(P/))  =»  j(i)  =  „'(i))}. 

where  free(P)  is  the  set  of  variables  appearing  free  in  the  predicate  P .  If  x  and  x' 
are  free  in  P/  and  there  exists  a  pair  (s,  s')  €  7 Zf  for  which  s(x)  ±  s'(x')  then  we 
say  that  a  modifies  x.  For  example,  an  action  a  €  As  that  increments  a  variable 
i  by  2  is  specified  by  the  predicate 

Pf  :  at(a)  A  ->after(a)  A  ~>at(a)'  A  after(a)’  A  x  =  x  +  2. 

The  action  a,  as  specified,  modifies  at(a),  after(a),  and  x. 

An  action  a  is  self- disabling  if  for  every  (s,t)  €  ,  there  is  no  u  €  S s  such 

that  ( t,u )  €  Thus,  after  a  completes  execution,  another  action  must  be 
executed  before  a  can  execute  again.  Henceforth,  we  restrict  consideration  to 
self-disabling  actions. 

2.1.3  Behaviors 

A  behavior  (of  a  specification  S)  is  an  infinite  sequence  a  €  where  for  every 
t,  a[i]  is  a  state,1  and  either  <7(1]  =  a[i  -I-  1]  or  there  exists  an  a  6  As  such 
that  (<7[»],<r[»  +  1])  G  .  A  property  is  a  set  of  behaviors.  We  assume  that  the 
property  defined  by  a  specification  S,  denoted  £5,  satisfies  two  restrictions.  The 
first  restriction  is  that  £5  be  closed  under  stuttering.  The  term  stuttering  refers 
to  finite  repetition  of  a  state  in  a  behavior.  Let  b(cr)  denote  the  state  sequence 
that  is  obtained  by  replacing  every  subsequence  of  identical  states  by  a  single 
instance  of  the  stuttered  state.  In  other  words,  tlfa)  is  stutter-free.  Requiring  £5 
to  be  closed  under  stuttering  means  that  if  a  €  £5  holds,  then  for  all  a'  such  that 
1  If  a  =  »o*i  •  •  -i  then  <r[»]  =  . . .,  and  <r[i..ji ]  =  5i«i  +  i . . .  s, . 
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ij(er)  =  holds,  o'  6  Bs  holds  as  well.  This  requirement  reflects  the  fact  that 
an  environment  cannot  distinguish  between  two  successive  identical  states,  and 
thus  two  behaviors  that  differ  only  by  stuttering  should  be  considered  equivalent. 
In  addition,  as  we  shall  see,  having  Bs  closed  under  stuttering  allows  for  a  nice 
correspondence  between  a  high-level  action  and  low-level  actions  that  implement 
it. 

The  second  restriction  on  Bs  is  that  it  be  tail  closed.  A  set  of  sequences  T 
is  tail-closed  if  for  every  o  €  T,  <r[l..]  g  T  holds.  Requiring  Bs  to  be  tail-closed 
guarantees  that  if  a  is  an  element  of  Bs  then  so  is  <r[t..]  for  every  i.  Tail-closure 
is  consistent  with  the  way  machines  execute  programs:  execution  of  a  machine  is 
based  entirely  on  the  machine’s  current  state.  Thus,  if  cr[0..]  is  a  behavior,  then 
it  is  evidence  that,  for  every  i,  if  the  specified  program  were  started  executing 
from  state  <r[i],  it  would  continue  through  all  the  states  in  o[i  + 1..],  making  <j[z..] 
a  behavior  as  well.  Technically,  tail-closure  is  helpful  if  one  wants  to  consider 
behaviors  as  models  for  temporal  logics  that  have  a  D-Generalization  rule  [MP81]. 

We  describe  85  by  conjunction  Azs  of  behavior  axioms.  An  infinite  sequence 
of  states  <7  is  in  85  if  and  only  if  it  satisfies  all  of  these  axioms.  Formally, 

BS  =  {*  £  Vf  |  a  |=  AiS}. 

Behavior  axioms  will  be  formulas  of  Temporal  Logic,  where  the  free  variables  are 
from  N(S).i  Thus,  85  is  the  set  of  all  models  (from  Hf)  of  Azs- 

The  requirements  that  85  be  closed  under  stuttering  and  that  it  be  tail  closed 
impose  restrictions  on  the  behavior  axioms.  We  consider  only  those  A 15  such 
that  for  every  o  where  o  f=  Azs  holds,  both  ijcr  f=  Azs  and  <r[l..J  (=  A15  hold 
as  well.  Also,  we  require  that  Azs  be  consistent  with  the  specification  of  the 
individual  actions.  That  is,  if  o  Azs ,  then,  for  every  *,  if  c[i  +  1]  ^  cr[i]  then 
there  exists  an  action  a  g  As,  such  that  (<r[*  +  1],  <x[*J)  [=  Pf . 

JWe  are  assuming  that  the  expressiveness  of  Temporal  Logic  [MP81]  suffices  for  the  behavior 
axioms. 
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In  Section  2.1.1  we  associated  constraints  with  the  set  of  states.  However, 
being  Boolean  expressions  over  iV(S),  constraints  are  Temporal  Logic  formulas 
and  can  be  considered  part  of  the  behavior  axioms.  This  leads  to  technically 
simpler  specifications,  and  this  is  the  approach  we  take. 

2.2  A  Simple  Specification 

As  an  example,  we  present  a  specification  (£#,.4#, 5#)  of  a  system  H  that 
increments  an  integer  variable  x  by  2.  The  system  consists  of  a  single  action 
a.  Thus,  Ah  =  M-  From  Ah,  we  conclude  that  at(a)  and  after(a)  must  be 
elements  of  the  domain  of  states.  Thus,  N(H)  =  {x,  at(a),  after(a)},  and  E#  is 
the  set  of  functions  that  map  x  to  an  integer  value  and  at(a),  after(a)  to  Boolean 
values.  Behavior  axioms  of  H  are: 

•  at(a)  =>  at(a)[) after(a) 

(If  the  entry  control  point  of  a  is  active,  then  it  stays  active  unless  the  exit 
control  point  becomes  active). 

•  -'(at(o)  A  after(a)) 

(A  constraint:  the  entry  and  exit  control  points  of  the  action  a  are  not 
active  simultaneously). 

•  at(a)  V  after(a) 

(A  constraint:  either  the  entry  control  point  of  a  or  its  exit  control  point 
are  active). 

•  after(a)  =»  Oafttr(oi) 

(If  the  exit  control  point  of  a  is  active  then  it  stays  active  thereafter). 

•  (VX  €  Z  :  ( at(a )  A  x  =  X)  =>  □  (after(a)  =>  x  =  X  +  2)) 

(If  the  entry  control  point  of  a  is  active  and  x  has  an  integer  value  X,  then 
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state  space:  N(H)  =  {x,  at(a),  after  (a)} 
actions:  Ap  =  {^} 

behaviors:  Specified  by  behavior  axioms: 

at(a )  =►  at(a)[}after(a) 

-'(at(a)  A  after(a)) 
at(a)  V  after(a) 
after(a)  =>  Oafter(a) 

(VX  €  Z  :  (ot(a)  A  x  =  X)  =►  D(a/iEer(a)  =>  i  =  X  +  2)) 

(VX  €  Z  :  (aftcr(a)  A  z  =  X)  =►  Dx  =  X) 

Figure  2.1:  A  specification  H. 

henceforth  if  the  exit  control  point  becomes  active  then  the  variable  x  will 
have  the  value  X  +  2). 

•  (VX  G  Z  :  (after(a)  A  i  =  X)  =>  Ox  =  X) 

(If  the  exit  control  point  of  h  is  active  and  the  variable  x  has  any  integer 
value  X,  then  x  will  have  the  value  X  thereafter). 

Figure  2.1  summerizes  this  specification.  Note  that  Axh  satisfy  the  requirements 
that  actions  be  self-disabling  and  that  behaviors  be  both  tail-closed  and  closed 
under  stuttering. 

2.3  Programs  sire  Specifications  Too 

Programs  can  be  regarded  as  defining  specifications.  As  a  specification,  the 
meaning  ai  a  program  P  is  (Ep,  Ap,Bp),  defined  as  follows.  The  set  of  variables 
N(P)  consists  of  explicit  as  well  as  implicit  variables  of  the  program.  Implicit 
variables  are  needed  because  when  a  programming  language  is  used  to  specify 
actions,  some  aspects  of  the  state  become  implicit.  For  example,  the  assignment 
statement  a:  x  :=  x  +  2  increments  a  variable  x  by  2,  assigns  false  to  the  control 
variable  at(a),  and  true  to  after(a).  In  a,  only  the  variable  x  is  explicit — both 
at(a)  and  after(a)  are  implicit  variables  of  the  action. 
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L:  Ida  x 
ina 
ina 
sta  x 
hit 
x:  ds 


/*  load  accumulator  with  x  */ 
/*  increment  accumulator  */ 

/*  store  accumulator  in  x  */ 
/*  halt  */ 

/*  define  storage  */ 


Figure  2.2:  A  specification  in  a  generic  assembly  language. 


The  set  of  actions  Ap  consists  of  all  atomic  actions  in  P. 

Finally,  the  behavior  axioms  Axp  are  encoded  in  the  text  of  P  and  the  se¬ 
mantics  of  the  programming  language. 

As  a  simple  example  of  how  to  regard  a  program  as  a  specification,  consider 
the  following  program  H,  given  in  a  Pascal- like  programming  language. 

H :  program 

var  x:  integer; 
a:  x  :=  x  +  2 
end 

As  a  specification,  program  H  is  identical  to  the  specification  H  of  Figure  2.1. 
Note,  though,  that  at(a)  and  after(a)  are  explicit  in  Figure  2.1  and  implicit  in 
program  H. 

Program  L  of  Figure  2.2,  can  also  be  regarded  as  specification.  It  is  written  in 
a  generic  assembler  language  and,  naturally,  specifies  details  that  do  not  appear 
in  a  program  of  a  high-level  programming  language.  Program  L  has  as  its 
variables  x,  an  accumulator,  and  control  variables  for  each  machine  instruction. 
Every  machine  instruction  defines  an  action.  The  axioms  encode  the  effect  of 
each.  It  should  be  obvious  that  programs  L  and  if,  and  specification  if ,  all 
specify  similar  behaviors.  In  Section  2.5,  we  formalize  such  relationships. 
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2.3.1  Associating  Control  Variables  with  Statements 

When  using  programs  to  write  specifications,  one  often  needs  to  specify  transfer 
of  control  between  non-atomic  as  well  as  atomic  statements.  For  that  purpose, 
we  associate  with  every  statement  T  the  control  variables  at(T),  in(T),  and 
after(T).  If  T  is  not  atomic,  then  the  assignment  of  values  to  T's  control  variables 
should  be  consistent  with  the  assignment  of  values  to  the  control  variables  of 
the  components  of  T.  Thus,  there  are  constraints  on  these  control  variables. 
Moreover,  these  constraints  are  of  a  special  form — they  define  the  value  that  a 
state  assigns  to  control  variables  of  T  in  terms  of  the  values  that  the  state  assigns 
to  the  control  variables  of  T’s  components.  For  this  reason,  the  control  variables 
of  T  are  derived  variables.3  For  example,  a  statement  T:  a  ;  b  comprising  of  two 
atomic  actions  a  and  b,  induces  the  following  definitions  for  its  derived  control 
variables4: 


at(T )  =  at(a) 
in(T)  =  at(a)  V  at(b) 
after(T)  =  after(b) 

2 A  External  and  Internal  Variables 

In  specifying  a  system,  one  must  distinguish  between  external  elements  (i.e., 

names  and  actions),  which  are  visible  to  the  environment,  and  internal  ones, 

which  are  invisible  to  the  environment.  For  example,  in  the  specification  of 

the  tickets  and  guard  services  of  Figure  1.1,  actions  getTicket(),  enter(),  and 

exitQ  are  external;  any  name  declared  inside  the  implementation  part  of  those 

services  is  internal.  Ideally,  one  would  like  to  specify  a  system  in  terms  of  what  is 

observable  by  the  environment — the  externals.  However,  such  specifications  tend 

to  be  cumbersome,  and  thus  internal  elements  sure  used  as  well.  For  example, 

3For  technical  reasons,  if  T  is  the  entire  program  then  after(T)  is  considered  primitive. 
4Assume  T  is  not  the  entire  program. 
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consider  the  specification  of  a  set  with  operations  to  add  and  remove  elements, 
and  an  operation  to  test  for  membership.  It  is  possible  to  specify  the  effect  of  a 
test  for  membership  operation  in  terms  of  the  sequence  of  the  preceding  add  and 
remove  operations.  However,  it  is  much  easier  to  maintain  the  contents  of  the  set 
in  some  variable,  having  add  and  remove  update  this  variable,  and  test  search 
it.  Such  a  variable  though,  is  not  (directly)  visible  to  the  environment,  which 
can  access  it  only  by  invoking  the  externally  visible  operations  add,  remove,  and 
test.  Thus,  the  variable  is  internal. 

We  use  (U).S  to  denote  a  specification  S  in  which  0  is  a  list  of  the  internal 
names.  The  behaviors  of  a  specification  (v).S  are  described  by  (3v  :  Axs).  The 
meaning  of  a  (3x  :  U),  where  a  is  an  infinite  sequence  of  states  and  U  a 
Temporal  Logic  formula  having  the  property  of  stutter  equivalence  (as  all  our 
behavior  axioms  do),  is  given  by 

<7  \=  (3x  :  U)  iff  there  exists  sequences  of  states  a'  and  a"  such  that 

•  Ijcr  =  I \cr'  (a1  is  a  stuttering  equivalent  of  a), 

•  a"  is  an  x-variant  erf  <ri,  i.e.,  differs  from  or'  by  at  most  the  value 
assignments  to  x,  and 

•  a"  (=  U. 

Classifying  the  elements  of  a  specification  5  into  externals  and  internals  par¬ 
titions  the  set  N(S)  of  names  ( of  variables)  into  the  disjoint  subsets  NE(S) — the 
external  names — and  #^(S) — the  internal  names.  It  also  partitions  the  set  As  of 
actions  into  the  disjoint  subsets  — the  external  actions — and  A$ — the  interned 
actions.  These  partitions  are  constrained,  though.  Control  variables  associated 
with  control  points  of  external  actions  are  external,  and  control  variables  associ¬ 
ated  with  control  points  of  internal  actions  are  internal.  Formally,  we  define: 

(2.1)  Consistent  ext/int  specification:  The  partitioning  of  N(S)  and  As  into 
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NE(S),  N^S),  and  AE,AJS  is  consistent  iff,  for  every  a  €  *45: 

a  €  A§  O  {at  (a),  after  (a)}  C  NE(S). 

As  a  simple  example,  consider  specification  H  given  in  Section  2.2.  A  classifi¬ 
cation  into  externals  and  internals  might  be,  for  the  variables  NE(H )  =  {1}  and 
N^H)  =  {at(a),  after(a)},  and  for  the  actions  A §  =  $  and  AJH  =  {o}.  This 
would  be  stated  as  the  specification  (at (a),  after(a)).H.  Classifying  x  as  external 
and  a  as  internal  implies  that  the  environment  can  observe  the  changes  in  x,  but 
it  cannot  observe  the  transfer  of  control  resulting  from  the  action  that  changes 
x.  This  classification  means  that  the  environment  cannot  distinguish  behaviors 
of  specification  H  from  behaviors  specified  by  program  L  of  Section  2.3 — both 
have  the  same  effect  on  variable  x.  Had  we  classified  a  as  an  external  action 
in  specification  H,  behaviors  specified  by  L  could  be  distinguished  from  those 
specified  by  H. 

2.4.1  Externally-visible  Parts  of  Behaviors 

The  distinction  between  external  and  internal  elements  of  a  specification  intro¬ 
duces  a  distinction  between  a  state  and  an  externally-visible  state.  An  externally- 
visible  state  is  a  state  with  domain  restricted  to  NE(S)  instead  of  jV(S).  Thus, 
an  externally-visible  state  provides  a  value  assignment  for  the  external  variables 
only.  The  externally-visible  part  of  state  a  €  E5  is  denoted  by  s\NE(Sy  An 
externally-visible  part  of  a  behavior  <r  is  the  sequence  of  externally-visible  states 
that  results  from  reducing  every  state  in  a  to  its  externally-visible  part.  We  use 
ct\nE(s)  to  denote  the  externally-visible  part  of  the  behavior  <7.  Note  that  an 
externally-visible  part  of  a  behavior  is  not  necessarily  a  behavior.  A  behavior 
might  have  successive  states  s,t  such  that,  for  some  internal  action  b,  ( s,t )  6  71$ 
and,  for  some  external  name  x,  s(z)  ^  t(x).  When  reduced  to  their  externally- 
visible  parts,  the  externally-visible  states  will  still  differ  (at  least  on  x)  but,  since 
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at(b )  and  after(b)  are  not  in  the  domain  of  the  externally-visible  states,  their 
control  part  will  not  reflect  the  execution  of  any  action. 

2.5  Implementations 

We  can  now  turn  to  the  question  of  what  it  means  for  one  specification  to  im¬ 
plement  another.  Consider  two  specifications  (u? ).L  (for  “low-level”)  and  (v).H 
(for  “high-level”).  Specification  (w).L  implements  (V).H  iff  the  externally-visible 
part  of  every  behavior  of  ( w).L  is  an  externally-visible  part  of  some  behavior  of 
(V).H.  Formally,  we  require  that  for  every  a  €  Bl  there  exists  a  a'  €  such 
that 

Thus,  (w).L  implements  (V).H  if  the  externally-visible  parts  of  a  and  a'  are  equal 
but  for  stuttering.  Note  that  because  this  definition  of  implements  is  in  terms  of 
a  reduction  to  externally-visible  parts,  NE(H)  =  NE(L )  is  a  necessary  condition 
for  £  to  be  considered  an  implementation  of  H. 

One  method  for  proving  that  ( w).L  implements  (v).H  is  to  define  a  function 

Flh  •  Zl  -*■  Lff, 

and  show  that  for  every  behavior  a  6  Bl,  the  sequence 

Flh{o[Q])Flh{°W)--- 

is  a  bekavior  in  Bjj.  If  for  every  s  €  the  value  assignment  to  the  external 
variables  provided  by  Flh(s)  is  identical  to  the  one  provided  by  s,  (i.e.,  for  every 
x  €  Ne(H),  s( x)  =  Flh(*)(x))i  then  one  can  establish  the  existence  of  the 
behavior  a'  in  the  definition  of  implements  simply  by  defining  a'  to  be  Fi^(cr), 
where 

Flh(t)  =  Flu(c{0})Flh^\\))  .... 

The  function  Flh  »s  called  a  refinement  mapping. 


Unfortunately,  Abadi  and  Lamport  have  proved  that  for  arbitrary  specifica¬ 
tions  L  and  H,  where  L  implements  H,  such  a  refinement  mapping  is  not  guar¬ 
anteed  to  exist  [AL88].  However,  they  also  proved  that  if  L  and  H  satisfy  certain 
restrictions,  then  it  is  possible  to  augment  L  with  additional  internal  variables 
T  (called  auxiliary  variables)  such  that  the  resulting  specification  L*  describes  a 
property  that  is  isomorphic  to  the  one  described  by  £.,  and  a  refinement  mapping 
from  E/;*  to  E#  does  exist.  We  call  L*  an  auxiliary  variables  augmentation  of  L. 
Thus,  asstuning  that  specifications  satisfy  the  restrictions  given  in  [AL88],5  we 
have  the  following  definition: 

(2.2)  Implements:  A  specification  (W).L  implements  a  specification  (v).H  if 
and  only  if 

1.  Ne(H)  =  Ne{L). 

2.  There  exist  L* ,  an  auxiliary  variables  augmentation  of  L,  and  refine¬ 
ment  mapping  Fm  :  E/;*  — ►  E#  such  that: 

(a)  for  every  s  6  and  for  every  x  6  NE(H),  s(x)  =  Flh(s)(x), 

(b)  (Va,(s,t)  :  a  €  Ag  A  (s,t)  G  :  (FLH(s),  FLH(t))  €  K*), 

(c)  for  every  a  €  Flh(<t)  6  Bu . 

Note  that  if  our  specification  language  has  the  property  that  for  an  external 
action  a  of  a  specification  S,  all  the  free  variables  in  Pf — the  predicate  that 
specifies  Hf — are  external,  then  requirement  2b  of  Implements  (2.2)  follows  from 

requirements  1  and  2a. 

Assoming  that  our  formal  language  is  rich  enough,  a  natural  way  to  define  a 

refinement  mapping  Fm  is  by  defining  an  expression  over  N(L)  for  every  variable 

name  in  N(H ).®  Let  mm  be  a  function  that  maps  every  variable  name  in  N(H) 

to  an  expression  over  the  variable  names  in  N(L).  Such  a  function  cm  be  used 

sThe  type  of  specifications  of  concern  in  this  thesis  satisfy  these  restrictions. 
sFor  simplicity,  in  the  following  discussion  we  ignore  the  fact  that  Flk  may  have  to  be  defined 
in  terms  of  an  auxiliary  variables  augmentation  of  L. 
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to  augment  every  state  s  €  E^,  adding  the  additional  variable  names  of  N(H)  to 
the  domain  of  s.  Given  refinement  mapping  Fm  is  any  function  from  E^ 

to  Eff  such  that  for  every  a  €  E 1  and  for  every  x  6  N(H ), 

Flh(*)(x)  =  s(mLH(x)).  (2.3) 

In  order  for  m m  to  describe  a  refinement  mapping,  it  must  both  be  a  function 
and  an  identity  function  for  external  variable  names.  That  is,  for  every  s  €  E^, 
v  e  N{H),  and  1  €  Ne(H), 

*(mLff(v))  is  uniquely  defined,  and  (2.4) 

™lh(x)  =  x.  (2.5) 

A  function,  like  mm ,  from  N(H )  to  expressions  over  N(L)  that  defines  a  refine¬ 
ment  mapping,  is  also  called  a  refinement  mapping. 

We  can  construct  mm  by  first  defining  an  expression  over  N(L)  for  every 
primitive  variable  in  N(H),  such  that  (2.4)  and  (2.5)  are  satisfied.  Then,  we 
define  expressions  over  N(L)  for  every  derived  variable  in  N(H).  Recall,  a  vari¬ 
able  d  €  N(H)  is  derived  because  it  appears  on  the  left-hand  side  of  a  definition, 
say  d  =  Ej,  where  Ed  is  an  expression  over  N(H).  For  every  derived  variable 
d  €  N{H),  we  define  m£j(d)  to  be  miff(Ed ),  where  mm  is  extended  to  expres¬ 
sions  in  the  usual  way  (e.g.,  mm(a  A  b)d=rnm(a)  A  miff(b)).  Since  every  derived 
variable  is  ultimately  defined  in  terms  of  the  primitive  ones,  this  completes  the 
definition  of  the  mapping  mm- 

To  illustrate  use  of  a  refinement  mapping  and  Implements  (2.2),  consider  the 
specification  given  by  program  L  of  Figure  2.3  and  program  H  of  Section  2.3. 

Assuming  that  NE(L)  =  NE(H)  =  {x},  one  would  expect  L  to  implement 
H.  Since  the  variable  y  is  internal,  the  externally-visible  part  of  a  behavior  of 
L  shows  only  changes  in  x,  and  both  H  and  L  make  the  same  changes — they 
increment  x  by  2.  We  will  not  give  a  full  proof  that  L  implements  H ,  but  will 
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L:  program 

var  x,y:  integer; 

/0:  y  :=  x; 
h-  V  :=  y  +  2; 

/2:  x  :=  y 

end 

Figure  2.3:  Incrementing  x  by  2  . . . 

present  mm — a  refinement  mapping  that  can  be  used  in  such  a  proof. 

=f  at(lo)  V  at(li)  V  af(/2) 
mm(after(a ))  =f  after(li) 
mui{x)  =f  x 

Note  that  if  the  action  a  were  external,  then  by  Consistent  ext/int  specifica¬ 
tion  (2.1),  at(a )  and  after(a)  would  have  been  externals  too,  and  this  mm 
would  not  work  because  it  violates  2a  of  Implements  (2.2).  In  fact,  if  a  were 
external,  then  the  only  possible  implementation  of  H  is  H  itself. 

2.5.1  Implementation  in  terms  of  the  Behavior  Axioms 

Defining  candidate  refinement  mappings  and  checking  them  by  testing  each  be¬ 
havior  is  often  infeasible.  Since  behaviors  are  characterized  by  behavior  axioms, 
testing  whether  a  candidate  refinement  mapping  shows  that  a  specification  L 
implements  a  specification  H ,  can  be  done  using  the  behavior  axioms  of  L  and 
H  rather  than  the  actual  behaviors  in  Bl  and  Bh- 

Using  behavior  axioms,  condition  (2c)  of  Implements  (2.2)  is  equivalent  to7 

(Ver  €  Xf  :  (<r  (=  Axl)  =►  {Fm(<r)  t=  Axh )).  (2.6) 

Similarly,  using  predicates  instead  of  relations  to  define  the  meaning  of  actions, 
condition  (2b)  of  Implements  (2.2)  is  equivalent  to 

(V«,(«,<)  '  a  €  A§  A  (»,*)  1=  Pi  :  (FLB(,\FlE(t))  |=  P“).  (2.7) 

7For  simplicity  we  omit  the  auxiliary  variables  augmentation  notation. 
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Assuming  that  our  formal  language  is  rich  enough  so  that  Fuj  can  be  defined 
syntactically  in  terms  of  a  function  like  mm  above,  we  can  use  (2.3)  to  argue 


that  equation  (2.6)  is  equivalent  to 

( Vcr  €  Ef  :  (<r  |=  Axl)  =>(cr  \=  mm(Axff )))  (2.8) 

=  (V<r  £  :  a  (=  {Axl  =>  mLff(Axff)))  (2.9) 

=  SJ*  h  (Ai£  =*>  miff(Axff)).  (2.10) 

Similarly,  using  (2.3)  and  (2.5),  equation  (2.7)  is  equivalent  to 

(Va,(s,t)  :  a  €  A§,  A(s,t)  j=  PaL  :  (s,  t)  f=  mLH(PE )).  (2.11) 


Thus,  using  the  above  equations  we  can  restate  Implements  (2.2),  as  follows: 

(2.12)  m-Implements:  A  specification  (W).L  implements  a  specification  ( v).H 
if  and  only  if 

1.  Ne(H)  =  Ne(L), 

2.  There  exist  £*,  an  auxiliary  variables  augmentation  of  L,  and  a  map¬ 
ping  mm  from  expressions  over  N(H)  to  expressions  over  N(LZ )  such 

that: 

(a)  For  every  s  €  E it,  v  6  N(H),  and  x  €  Ne(H), 

i.  s(miff( v))  is  uniquely  defined,  and 

ii.  mLH(x)  =  x. 

(b)  (Va,(s,<) :  a  €  -4g,  A  (s,t)  Pf*  :  (s,  t)  h  mLH(PE )), 

(c)  E^i  h  (Ax/;*  =>  miff(Axff)). 

We  should  point  out  that  under  the  assumption  that  the  formal  language  we 
use  to  express  mm  is  rich  enough,  definition  Implements  (2.2)  and  definition 
m-Implements  (2.12)  are  equivalent. 
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Using  the  definition  of  ,  condition  2c  of  m -Implements  (2.12)  is  equivalent 
to 

^  (AZL*  ^  (AXH (2-13) 
where  u,u,u>, ...  denote  the  variable  names  in  N(H).  By  condition  2a  of  m- 
Implements  (2.12),  Equation  (2.13)  is  equivalent  to 

N  =►  (2-14) 

where  mm(V)  denotes  the  list  ttilh{vi)i  mLH(v2),  •  •  ••  Assuming  that  internal 
variables  in  specification  ( w).L  are  named  differently  than  the  internals  in  (v).H, 
we  have,  by  definition  of  miff,  that  for  any  vj  £  v,  Vj  is  not  free  in  mm(vj). 
Thus,  by  predicate  logic,  we  infer  that  (2.13)  is  equivalent  to 

E?  f=  (Ax^t  ^  ( 3v  :  v  =  mm( v)  :  Axh)).  (2-15) 

By  predicate  logic,  from  Equation  (2.15)  we  infer 

E?  \=  (AxLt  =>  (3c  :  Axu)).  (2.16) 

In  general,  Equations  (2.15)  and  (2.16)  are  not  equivalent.  Thus,  in  the  general 
case,  given  Equation  (2.16),  one  has  no  guarantee  that  a  function  such  as  mm 
can  be  found  so  that  (2.15)  can  be  established.  However,  due  to  the  fact  that 
specifications  considered  by  this  work  satisfy  the  requirements  for  completeness 
of  [AL88],  and  the  assumption  that  our  formal  language  is  rich  enough  to  express 
the  refinement  mapping,  (2.15)  and  (2.16)  can  be  considered  equivalent. 


Chapter  3 

Proof  Outlines  as  a  Specification 
Language 


Proof  outlines  [Sch]  are  useful  in  reasoning  about  safety  properties  [Lam77] — 
sets  of  behaviors  in  which  certain  finite  prefixes  (regarded  as  “bad”  things)  are 
prohibited.  Proof  outlines  can  also  be  used  in  deriving  programs  that  satisfy  a 
given  safety  property. 

In  this  chapter,  we  explain  how  to  interpret  a  proof  outline  as  a  specification. 
We  then  detail  conditions  that  imply  one  proof  outline  implements  another.  In 
general,  these  conditions  can  be  complex.  However,  when  one  proof  outline  is 
structurally  related  to  the  other  (as  defined  later  in  this  chapter),  these  conditions 
can  be  simplified.  This  structural  relationship  between  proof  outlines  along  with 
a  theorem  characterizing  when  a  proof  outline  that  is  structurally  related  to 
another  proof  outline  implements  it  are  the  basis  of  our  methodology  for  deriving 
multiple-server  implementations  of  a  service  from  single-server  implementations 
of  that  service.  That  methodology  is  presented  in  Chapter  4. 
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3.1  Program  Proof  Outlines 

A  proof  outline  is  a  program  annotated  with  assertions  before  and  after  every 
statement.  Assertions  are  predicates  in  which  the  free  variables  are  the  explicit 
and  implicit  variables  of  the  program.1  In  a  proof  outline  PO(S)  for  a  program 
5,  the  assertion  associated  with  the  control  point  at(T),  where  T  is  a  statement 
in  5,  appears  just  before  the  statement  T  and  is  denoted  preP0^(Ty,  the  as¬ 
sertion  associated  with  the  control  point  after(T)  appears  immediately  after  T 
and  is  denoted  postP0^^(T).  The  term  triple  denotes  a  proof  outline  of  the  form 
{P}T{Q}  where  P  and  Q  are  assertions  and  T  is  a  statement.  An  example  of  a 
proof  outline  appears  in  Figure  4.1. 

A  proof  outline  PO(S)  is  valid  iff  for  every  execution  a  of  S,  if  o  starts  in  a 
state  where  assertions  associated  with  active  control  points  hold,  then  in  every 
state  of  a,  assertions  associated  with  active  control  points  hold.  When  a  proof 
outline  PO(S)  that  is  valid  is  viewed  as  a  specification,  every  execution  of  5 
that  starts  in  a  state  where  the  assertions  associated  with  active  control  points 
hold  is  a  behavior  of  P0(5).  However,  in  viewing  PO(S)  as  a  specification,  we 
would  also  like  to  argue  that  executions  of  programs  other  than  5  be  regarded 
a s  behaviors  of  PO(S).  As  we  already  know,  this  can  be  achieved  by  classifying 
the  variables  and  actions  of  a  specification  into  externals  and  internals.  Thus, 
generally,  a  proof-outline  specification  is  denoted  ( v).PO(S ),  where  v  denotes  the 
internal  variables. 

The  meaning  of  (v).PO(S),  is  given  by  (E/»o(S)M/>o(5).bpo(S))-  The  state 
space  £po(S)  is  the  state  space  of  program  S,  as  characterized  in  Section  2.3.  The 
set  of  actions  «4/>o(S)  is  determined  from  the  statements  of  5  in  a  way  described 
in  3.1.1  below.  The  set  of  behaviors  B Po[S)  depends  on  the  behaviors  specified 
by  program  5  and  the  assertions  of  PO(S);  it  is  defined  in  3.1.2  below.  The 

lFor  simplicity,  we  ignore  the  rigid  variables  of  a  proof  outline.  It  is  straightforward  to  include 
them. 
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definitions  we  give  are  language  independent,  as  was  the  definition  of  £$  in 
Section  2.3. 

3.1.1  Actions  of  a  Proof  Outline 

The  set  Apo^s)  of  actions  specified  by  proof  outline  PO(S)  is  the  same  as  ^.5 — 
the  set  of  all  atomic  actions  of  program  S.  As  is  determined  by  the  statements 
of  S  and  how  they  are  composed. 

The  semantics  of  a  programming  language  generally  defines  certain  statement 
types  to  be  atomic.  It  also  defines  certain  statement  construction  rules  that  can 
be  used  in  composing  statements  to  obtain  new  ones.  For  example,  the  atomic 
statements  of  Guarded  Commands  [Dij76]  as  extended  in  [Sch]  are  assignment 
and  skip ,  and  the  statement  construction  rules  correspond  to  composition (;); 
altemation( if  ...fi),  iteration( do  ...od),  and  concurrent  composition^ cobegin 
. . .  coend).  For  a  given  language,  let  Atom(T)  be  a  Boolean  function  that  is  true 
if  statement  T  is  atomic,  and  let  Gi,...  ,  Gn  denote  the  statement  construction 
rules  defined  by  the  language,  where  T  =  G,(Xi, . . .  ,7*)  denotes  the  fact  that 
statement  T  is  constructed  of  statements  Ti, . . . ,  7*  by  rule  G,.  For  example,  we 
expect  that  Atom(x  :=  2  +•  1)  holds,  Atom(x  :=  2  4- 1;  d  :=  5)  does  not  hold,  and 
that 

T:  x  :=  2  +  1 ;  d  :=  5 

is  the  composition  of  Ti:  x  :=  z  -f  1  and  T 2:  d  :=  5,  so  we  have  T  —  G;(Ti,  T2). 

Some  statements  are  guarded  and  may  execute  in  a  state  only  if  that  state 
satisfies  a  guard.  We  use  B  —*  T  to  denote  such  a  guarded  statement,  where  B 
is  the  guard.  The  guarded  statement  a:  x  >  0  —*  x  :=  x  —  l  denotes  a  statement 
that  can  execute  in  a  state  s  only  if  both  $(at(a))  and  s(x)  >  0  hold.  Since 
the  semantics  of  true  — ►  T  is  identical  to  the  semantics  of  T,  we  consider  every 
statement  to  be  guarded. 

Composing  B\  — *  Ti, . . . ,  B*  — ►  T*,  using  statement  construction  rule  G,,  pro- 
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duces  a  statement  T  =  Gi(Bi  — ►  T\,. . .  ,B^  — ♦  X*).  In  general,  this  composition 
produces  an  implicit  action,  gj  =  gGi{B\->Tx,...,Bk—Tk)t  possibly  null,  that  is  part 
of  T  and  is  used  to  coordinate  the  components  of  T.  For  example,  the  implicit 
action  might  be  one  that  evaluates  the  guards  of  the  component  statements,  and 
based  on  the  results,  selects  a  particular  component  for  execution.  We  will  as¬ 
sume  that  this  implicit  action  is  atomic.  Thus,  for  any  such  gf,  Atom(gx)  is 
true. 

In  Guarded  Commands,  the  implicit  action  of  the  composition  construction 
rule  (i.e.,  G-)  is  empty,  whereas  the  implicit  action  associated  with  iteration 
construction  rule  (i.e.,  G& 0)  is  not  empty.  For 

T  =  Gdo(Bi  ->  Ti, . . . ,  Bk  -*  Tk), 

the  implicit  action  gr  is  required  to  select  a  component  guarded  statement,  say 
Bi  — ►  Ti,  such  that  B{  holds,  and  transfer  control  to  T,  (i.e.,  at(T,)  becomes 
true);  if  such  B ,•  — +  Ti  cannot  be  found,  control  is  transferred  to  the  statement 
immediately  following  T  (i.e.,  after(T)  becomes  true). 

A  statement  or  an  implicit  action  is  called  an  executable  unit.  We  assume 
that  a  program  is  a  statement,  thus  an  executable  unit.  For  an  executable  unit 
T,  let  Comps{T)  denote  the  set  of  the  components  of  T, 

Comps(T) 

and  let  Comps* (T)  denote  the  reflexive  transitive  closure  of  Comps(T).  The  set 
As  of  the  atomic  actions  of  program  5  is  defined  as 

As  =  {«£  Comps*(S)  |  Atom(a)}. 

3.1.2  Behaviors  of  a  Proof  Outline 

The  behavior  axioms  of  a  proof  outline  PO(S)  guarantee  that  if  PO(S)  is  valid 
then  every  execution  of  5  that  starts  in  a  state  where  assertions  associated  with 


$  if  Atom(T) 

l  {sr.r, . 71}  ifr  =  G,(B,  -r, . 


(3.1) 
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active  control  points  hold,  is  a  behavior  of  PO(S).  The  behavior  axioms  involve 
control  axioms  CAs  and  an  invariance  axiom  Inv(PO(S)).  The  control  axioms 
characterize  the  behaviors  with  respect  to  the  control  variables.  They  guarantee 
that,  with  respect  to  control,  behaviors  can  be  considered  executions  of  a  program 
with  the  same  structure  as  S.  For  example,  in  an  execution  of  a  program,  it  is 
never  the  case  that  both  the  entry  and  exit  control  points  of  the  same  action 
are  active  simultaneously.  Also,  it  is  always  the  case  that  if  the  entry  control 
point  of  an  action  is  active  then  it  stays  active  until  that  action  is  executed.  The 
control  axioms  guarantee  that  behaviors  satisfy  the  above,  and  other,  control 
requirements. 

The  invariance  axiom,  denoted  Inv(PO(S)),  further  restricts  behaviors  based 
on  the  assertions  in  PO(S).  Its  purpose  is  to  guarantee  that  states  in  a  behavior 
satisfy  assertions  corresponding  to  the  active  control  points  in  a  state. 

Formally,  B(V).po(s),  the  set  of  behaviors  specified  by  ( v).PO(S ),  is  given  by 

Bw.po(s)  =  {<r  €  T,f  |  \=  (3u  :  CAS  A  7m< PO(S)))}.  (3.2) 

In  the  following  subsections,  we  present  the  control  and  invariance  axioms  in 
detail. 

Control  Axioms 

The  control  axioms  for  a  proof  outline  PO(S)  depend  on  the  program  5  and  the 
semantics  of  the  programming  language.  Recall  that  in  Section  2.1.3  we  stated 
that  constraints  would  be  included  in  the  behavior  axioms.  In  keeping  with 
that  decision,  the  first  two  types  of  control  axioms  are  those  that  constrain  the 
assignment  of  values  to  control-variables. 

Recall  that  definitions — formulas  of  the  form  x  =  E,  where  x  is  a  variable  and 
E  is  an  expression  involving  variables — are  a  special  type  of  constraint.  For  an 
executable  unit  T,  let  DEF(T)  denote  a  set  of  definitions  and  let  CNSR (T)  denote 
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the  set  of  remaining  constraints.  The  set  DEF(F)  is  defined  as 


DEF(T)  =  ■{ 


{“tn(T)  =  at(T)" 
[D*t(T)iDin{T)) 

'  A»(7>  " 

k  D‘ft‘r(T) 


}  if  Atom(T ) 

if  T  is  the  whole  program 

if  T  =  Gj(B\  -+  Tlt. . . ,  Bk  -+  Tk) 


(3.3) 


where  Dx  denotes  the  definition  ux  =  Bx"  and  Bx  is  a  Boolean  expression  over 
control  variables.  For  any  primitive  control  variable  x  we  define  Dx  to  be  the 
null  formula.  Note  that  for  a  program  T,  according  to  (3.3),  the  control  variable 
after(T)  is  primitive.  Let  DEF*(T)  denote  the  transitive  closure  of  DEF (T): 


DEF*(T)  =  DEF(T)  U  (  (J  DEF*(Q)).  (3.4)' 

Qe  Comps(T) 

The  control-variable  definitions  specified  by  a  program  5  are  the  elements  of 
DEF*(S). 

The  set  CNSR(T)  of  the  remaining  constraints  of  T,  is  defined  as 


CNSR(T) = 


$  if  Atom(T) 

{Bi  |  /  =  1 . . .  nj1}  otherwise 


(3.5) 


where  B i, . . . ,  Bnr  are  Boolean  expressions  over  the  control  variables  of  Comps(T) 
and,  possibly,  T.  Let  CNSR*(T)  be  defined  by 


CNSR*(T)  =  CNSR(r)  U  (  (J  CNSR*(<?)).  (3.6) 

Q€  Comps(T) 

The  set  CNSR*(S)  consists  of  the  remaining  constraints  of  program  S. 

The  third  type  of  control  axioms  are  persistence  axioms.  A  persistence  axiom 
states  that  an  entry  control  point  that  becomes  active  will  stay  active  until  its 
associated  action  executes.  Only  execution  of  an  action  a  can  deactivate  control 
point  at(a)  and  activate  control  point  after(a).  Formally,  the  persistence  axiom 
for  action  a  is  □(in(a)  ^  ( in(a)\iafter(a ))). 
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me  fourth  and  final  type  of  control  axiom  is  the  termination  axiom.  The  ter¬ 
mination  axiom  captures  the  fact  that  once  the  control  point  at  the  end  of  the  pro¬ 
gram  becomes  active,  it  stays  active  thereafter.  It  is  n(after(S)  =>  Q(after(S))). 
A  termination  axiom  allows  finite  executions  (execution  of  terminating  programs) 
to  be  viewed  as  infinite  ones,  where  the  state  at  termination  is  stuttered  ad  in¬ 
finitum. 

In  summary,  the  control  axioms  of  proof  outline  specification  PO(S)  are: 

CA  1  (definitions)  The  set  DEF*(S) 

CA  2  (constraints)  The  set  cnsr*(5) 

CA  3  (persistence)  A aeAs  a(*«(a)  =>  (in(a)Uafter(a))) 

CA  4  (termination)  D(after(S)  =*-  □(o/ter(5))) 


□ 


Invariance  Axiom 

An  invariance  axiom  asserts  the  invariance  of  the  proof-outline  invariant 

Ipo(S):  A  at(a)  =*  PrePO{S)(a)  A  after(S)  ^  postPO{s](S).  (3.7) 

•€As 

Formula  Ipo(S)  *s  formal  statement  of  the  requirement  that  whenever  a  con¬ 
trol  point  is  active  in  a  state,  its  corresponding  assertion  holds  in  that  state. 
The  invariance  axiom  restricts  behaviors  to  be  only  sequences  where  every  state 
satisfies  (3.7).  Formally, 

Inv(PO(S)):  □  IPoiS).  (3.8) 

3.2  Defining  ‘Implements’  for  Proof  Outlines 

We  now  turn  to  the  question  of  what  it  means  for  one  proof  outline  to  implement 
another.  Since  proof  outlines  are  specifications,  the  answer  to  this  question  is 
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given  by  Implements  (2.2).  However,  in  order  to  use  logic  for  arguing  ‘imple¬ 
ments’  we  use  the  equivalent  definition,  m-Implements  (2.12).  In  the  following, 
we  discuss  the  details  of  using  this  definition  when  proof  outlines  are  involved. 

Consider  two  proof  outline  specifications:  (v).PO(H),  and  PO(L).  According 
to  m-Implements  (2.12),  in  order  to  prove  that  PO(L)  implements  (' V).PO(H ) 
one  must  show  that  conditions  1  and  2  hold. 

Conditions  1  and  2a  are  straightforward. 

In  the  case  of  proof  outlines,  we  can  show  that  2b  is  redundant — it  follows 
from  1  and  2(a)ii.  To  see  this,  observe  that  in  proof  outlines,  actions  are  specified 
by  programming  language  statements.  If  such  a  statement  specifies  am  external 
action,  then  it  would  have  to  appear  unchanged  in  any  implementation.  Thus, 
any  internal  variable  mentioned  in  that  statement  would  have  to  become  part' 
of  every  implementation.  Internal  variables  that  are  so  constrained  are  indistin¬ 
guishable  from  external  variables.  So,  when  proof  outlines  are  used  as  specifica¬ 
tions,  external  actions  must  be  specified  by  statements  involving  only  external 
variables.  We,  therefore,  conclude  that  for  an  external  action  a  £  Ay,  all  free 
variables  of  Pj*  are  externals.  This  conclusion,  together  with  NE{L)  =  NE(H) 
(condition  1)  implies  that  PE  =  PE  =  Pa.  From  condition  2(a)ii  we  infer  that 
Pa  =  miu(Pa),  and  thus  conclude  that  condition  2b  holds  whenever  1  and  2(a)ii 
do. 

Finally,  in  order  to  satisfy  condition  2c,  we  must  prove 

( CAl  A  Qlpo(L))  =►  ™Lh{CAh  A  ^Ipo(H))-  (3.9) 

However,  showing  that  (3.9)  holds  might  be  difficult.  In  particular,  since  a  vari¬ 
able  name  x  €  NJ(H)  is  mapped  by  rniy  to  an  expression  over  N(L),  any  sepa¬ 
ration  between  control  and  invariance  in  behavior  axioms  CAy  A  ^Ipo(H)  might 
disappear  in  rniy{CAy  A  ^lpo(y))-  Fortunately,  if  PO(L )  is  not  an  arbitrary 
proof  outline,  but  one  where  the  structure  of  program  L  resembles  the  structure 
of  program  H ,  then  rniH  can  be  constructed  such  that  internal  control  variables 
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of  H  are  defined  only  in  terms  of  control  variables  of  L.  This  simplifies  the  proof 
of  (3.9)  and  provides  a  standard  way  to  define  mm  for  control  variables,  as  we 
now  see. 


3.3  Structural  Refinements 

A  program  R  is  a  structural  refinement  of  a  program  A  if  the  control  structure  of 
A  is  an  abstraction  of  the  control  structure  of  R.  We  formalize  this  definition  as: 

(3.10)  structural  refinement  of  executable  units:  An  executable  unit  V  is 
a  structural  refinement  of  an  executable  unit  T  iff 

•  Atom(T),  or 

•  T  =  Gi(B1^T1,...,Bk->Tk),r  =  Gi(B'1-+T[,...,B'k-+T'k),  and 

for  every  j  €  1 ...  k,  Tj  is  a  structural  refinement  of  Tj,  or 

•  T'  is  an  auxiliary  elements  augmentation  of  some  T" ,  and  T"  is  a 
structural  refinement  of  T. 

For  example,  program  L  in  Section  2.3  is  a  structural  refinement  of  the  program 
H  in  Section  2.3.  This  is  due  to  the  fact  that  H  consists  of  a  single  atomic  action 
a,  thus  any  program  will  be  a  structural  refinement  of  H.  As  another  example, 
consider  the  following  statement  T, 

T:  if  x  >  0  — ♦  i  :=  -i  |  z  <  0  — ►  skip  fi 

A  structural  refinement  of  T  must  be  an  if  with  two  guarded  statements.  The 
guarded  statements,  however,  cam  be  somewhat  more  complex.  For  example,  the 
following  statement  T1  is  a  structural  refinement  of  T: 

T':  if  x  >  0  — ►  do  x  >  0  — ►  x  :=  —  x  od 
fl  x  <  0  x  :=  x 

fi 
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Statement  TM  below  is  not  a  structural  refinement  of  T : 

T":  if  x  >  0  — +  dox>0  — ►  x  :=  — x  od 
11  x  <  0  -f  x  :=  x 
J  x  =  0  — ►  skip 
fi 

The  following  technical  lemma  relates  Comps*(T')  and  Comps*(T),  when  T‘ 
is  a  structural  refinement  of  T.  It  will  be  useful  in  stating  our  main  results. 

Lemma  1  If  T'  is  a  structural  refinement  ofT  then  there  exists  a  total  mapping 
h  :  Comps*(T )  — ►  Comps*(T')  such  that  for  any  c  €  Comps*(T),  h(c)  is  the 
element  of  Comps* (T1)  that  is  the  structural  refinement  of  c. 

Proof :  By  induction,  using  the  definition  of  structural  refinement.  □ 

The  definition  of  structural  refinement  for  executable  units  can  be  extended 
to  proof  outlines  as  follows: 

(3.11)  Structural  refinement  of  proof  outlines:  (iu).PO(T'')  is  a  structural 
refinement  of  (V).PO(T)  iff  T1  is  a  structural  refinement  of  T,  and,  for 
every  a  €  A$,  h(a)  is  identical  to  a. 

The  significance  of  identifying  structural  refinements  when  proving  that  one 
proof  outline  implements  another  is  captured  by  the  following  theorem.  It  shows 
that  a  predefined,  generic,  mapping  of  the  control  variables  of  N(A)  can  be 
used  in  constructing  a  refinement  mapping  to  prove  that  (w).PO(R),  a  structural 
refinement  of  (V).PO(A),  implements  (v).PO(A). 

Theorem  2  (implements)  If{w).PO{R)  is  a  structural  refinement  of  (v).P 0(A) 
and  NE(R)  =  NE(A),  and  if  there  exists  a  function  m  from  N(A)  to  N(R)  that 
satisfies  the  following  conditions 
H-l  For  every  x  €  NE(A): 

m(x)  =  x 
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H-2  For  every  a  6  -A a'. 

m(at(a))  =  in(h(a)) 
m{after(a))  =  after(h(a)) 

H-3 


m(after(A))  =  after(h(A )) 

H-4  For  every  derived  control  variable  x  6  N(A): 

m(x)  =  m(Bx),  where  “x  =  Bx ”  €  DEF*(A) 
H-5  If  e\  +  e2  is  an  expression  over  jV(/1)  then 

m(e i  *e2)  =  m(e\)  *  m(e2) 

H-6 

AaeAA^POiR)  A  ^(^(a)))  =>  ™(p™po(A){< »))) 
ho(R)  A  rn(afier(A))  =>  m(postPO{A)(A )) 

then  PO(R )  implements  (V).PO(A). 


In  the  proof  of  Theorem  2  (implements),  we  reason  about  control  variables. 
To  do  so,  we  must  assume  that  the  semantic  description  of  the  programming 
language  provides  the  necessary  apparatus.  Among  other  things,  we  must  assume 
that  the  control  axioms  are  strong  enough  so  that  we  can  prove  certain  true  things 
about  control  aspects  of  the  state.  Since  Theorem  2  (implements)  is  formulated 
in  a  manner  that  is  independent  of  the  particular  programming  language  being 
used,  we  must  make  some  assumptions  about  the  logical  apparatus  available  to 
us  for  reasoning  about  control  variables. 

The  irst  assumption  we  make  is  that  the  set  DEF*(5) — the  definitions  of 
derived  control  variables  of  program  5 — allows  every  derived  control  variable 
to  be  expressed  in  terms  of  primitive  control  variables  only.  We  say  that  the 
set  DEF*(S)  is  sufficient  iff  for  every  derived  control  variable  x,  the  expression 
Bx  (in  the  definition  Dx)  can  be  reduced  to  an  equivalent  expression  over  only 
primitives,  by  repeatedly  replacing  derived  control  variables  by  their  definitions 
in  DEF*(S).  Henceforth,  we  assume  that  DEF *(S)  is  sufficient. 
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The  second  assumption  we  make  is  that  the  control  axioms  imply  that  derived 
control  variables  are  related  properly  to  the  control  variables  of  the  components 
of  their  statement. 

(3.12)  consistent  control  axioms:  For  every  T  €  Comp3*(S),  CAs  implies: 


at(T)  =>  in(T) 

(3.13) 

A  (•*»(«)  =►  *»cn) 

(3.14) 

ag  Comfi*(T) 

in(T)  =>  \J  *n(a) 

(3.15) 

a€  Compt*(T) 

->(in(T)  A  after(T)) 

(3.16) 

in(T )  =>  (in(T)U after (T)) 

(3.17) 

The  third  assumption  is  that  constraints  (and  definitions)  reflect  the  structure 
of  the  program.  Some  aspects  of  control  reflect  the  manner  in  which  executable 
units  have  been  composed.  Thus,  control  axioms  should  be  referentially  trans¬ 
parent  with  respect  to  this  composition.  Formally, 

(3.18)  structure:  For  any  statements  T  and  T',  such  that  T  =  G{(0\, .  ..,0k) 
and  V  —  Gi(0\, ... ,  0'k )  (where  0,  denotes  C,  — ♦  T{ ),  if  B  6  CNSR(r)  then 
€  CNSR(T').  Similarly  for  B  €  DEF(T). 

Our  fourth  and  last  assumption  about  the  control  semantics  of  the  program¬ 
ming  language  restricts  constraint-expressions — elements  of  CNSR*(S)  or  right 
hand  sides  of  definitions  in  DEF*(S) — for  S.  To  understand  the  need  for  this 
assumption,  recall  that  when  PO(L)  is  a  structural  refinement  of  PO(H),  an  in¬ 
ternal  (atomic)  action  a  6  Ay  is  structurally  refined  by  h(a)  €  Comp$*(L ),  where 
h(a)  is  not  necessarily  atomic.  By  structure  (3.18),  every  constraint-expression 
of  PO(H)  that  involves  a  has  a  matching  constraint-expression  of  PO(L )  where 
references  to  a  are  replaced  by  references  to  h(a).  This  means  that  for  any  be¬ 
havior  of  PO(L ),  whenever  control  is  either  at  the  start  of  h(a)  or  at  the  end 
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of  h(a),  states  are  constrained  to  satisfy  these  matching  constraint-expressions. 
When  such  states  are  viewed  as  states  of  PO(H),  they  satisfy  the  constraint- 
expressions  involving  a.  This,  however,  is  not  enough  because  we  have  decided 
that  states  in  PO(L )  for  which  control  is  inside  h(a)  will  be  viewed  as  states  in 
PO(H )  for  which  control  is  at  the  start  of  a.  Thus,  a  state  of  PO(L)  in  which  a 
control  point  inside  h(a)  is  active,  must  satisfy  constraint-expressions  involving 
at(a )  when  viewed  as  a  state  of  PO(H).  This  leads  to  a  requirement  that  if 
states  of  PO(L)  satisfy  constraint-expressions  involving  at(/i(a))  and  after(h(a)) 
they  must  also  satisfy  the  same  constraint-expressions  where  every  occurrence  of 
at(h(a))  is  replaced  by  in(h(a)).  We  call  this  property  coverage  since  it  implies 
that  constraint-expressions  hold  for  all  the  control  points  covered  by  in(h(a)). 
Note,  for  atomic  h(a)  this  requirement  is  trivial  since  at(h(a))  =  in(h(a)). 

(3.19)  coverage:  For  any  program  S,  if  “ x  =  2?”  is  in  DEF*(S)  or  B  is  a  con¬ 
straint  in  CNSR*(S),  and  if  B'  is  any  expression  derived  from  B  by  replac¬ 
ing  derived  variables  in  B  by  the  right  hand  side  of  their  definition  from 
DEF*(S),  then2 

(def*(S)  a  cnsr*(S))  =>  (B1  =>  (B')£). 

In  proving  Theorem  2  (implements)  we  use  several  lemmas,  which  we  present 
here  together  with  their  proofs. 

Lemma  3  (invariance)  If  H-l  through  H-6  hold,  then  the  following  formula  is 
valid: 

bo{R)  =>  m(Ipo(A)) 

Proof: 

1  Ipo{R)  ^  m(Ipo(A)) 

2The  notation  E$l  is  a  shorthand  for  where  af(u),af(v), . . .  denote  all  the  at 

control  variables  in  E. 
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11  bo(R) 

1.2  Consider  any  a  €  A  a 

1.3  m(at(a))  =*  rn(prePO(A)(a)) 

1.3.1  m(at(a)) 

1.3.2  IP0{R)  A  m(a*(a)) 

1.3.3  m(prePOiA)(a)) 

14  Aae^  m(ai(a))  =*  rn(prePO{A)(a)) 
1-5  rn{/\a&AA(at(a)  =>  preP0{A)(a))) 
1.6  m(after(A))  =*►  m(postPO{A)(A )) 

1.6.1  m(after(A)) 

1.6.2  m(pos^oM)(A)) 

1.6.2. 1  I Po(R)  A  m(after(A)) 

16.2.2  m(posiPO(yl)(/l)) 

1.6.3 


assumption 


assumption 
A  -  incl  on  1.1,  1.3.1 
MP  H-6,  1.3.2 
1.2,  1.3 
1.4,  H-5 


assumption 

A  -incl  on  1.1,  1.6.1 
MP  1.6. 2.1,  H-6 
1.6.1,  1.6.2 


1-7  rn(AaGAA{at(a)  ^  preP0(A)(a)))  A  (m(after(A))  =►  nrx{postpo(A]{A))) 

A  -incl  1.5,  1.6 

1-8  ™(A azAA{at(a)  =>  prtpo{A)(a))  A  (m(after(A))  =>  m(postPO(A)(A)))) 

H-5  on  1.7 


1.9  m(IP0{A)) 


1.8,  Equation  (3.7) 


□ 


Lemma  4  (unless)  If  H-l  through  H-6  hold,  then  the  following  formula  is  valid: 

/\beAA  D(»»(M&))  =>  (»T»(/*(6))UayiEer(A(6))))  =» 

D(m(at(b))  ^  (m(at(b))\Jm(after(b)))). 
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Proof : 

1  Consider  any  b  €  A\ 


2  D(in(h(b))  =S>  (in(/i(i))Ua/tcr(A(6))))  =» 

□(m(af(fe))  =►  (m(a£(6))Um(a/i!er(&)))) 


2.1  □(in(h(6))  =>•  (in(h(b))U  after  (h(b)))) 

2.2  m(at(b))  =  in(h(b )) 

2.3  □(m(a£(&))  =  in(h(b ))) 

2.4  □  (m(a£(6))  =>  (m(at(b))[i after (h(b)))) 

2.5  m(after(b ))  =  after(h(b)) 

2.6  □(m(a/ter(6))  =  after(h(b))) 

2.7  □(m(a£(6))  =>  (m(at(b))[)m(after(b)))) 


assumption 
1  and  H-2 
□-generalization,  2.2 
TL  2.1,  2.3 
1  and  H-2 
□-generalization,  2.5 
TL  2.6,  2.4 


3  By  2  and  1  conclude 

A*€At  D(l'n(M6))  =►  (in(h(b))[i after (h(b))))  =S> 

□(m(a£(6))  ^  (m(at(b))\)m(after(b)))). 

a 


The  next  lemma  shows  that  m,  as  defined  in  Theorem  2  (implements),  pre¬ 
serves  the  constraints  of  specification  PO(A).  Thus,  a  constraint  B  E  cnsr*(A) 
is  mapped  by  m  to  a  formula  m(B)  that  holds  at  any  state  of  a  behavior  of 
PO{R). 

Lemma  5  (constraints)  If  the  hypotheses  of  Theorem  2  (implements)  hold,  then 
for  any  constraint  B  €  CNSR*(A),  the  formula  (DEF*(B)  A  CNSR*(B))  =>  m(B)  is 
valid. 


Proof:  For  a  definition  “i(T)  =  BX{T)”  DEF*(j4),  define  a  Dx  (T}  expansion 

step  to  be  substitution  of  the  expression  Bz^)  for  all  the  occurrences  of  a  derived 
control  variable  x(T),  where  x  can  be  “at”,  “in”,  or  “ after ”,  and  T  is  an  exe¬ 
cutable  unit.  Consider  any  constraint  B  in  CNSR*(A).  Let  Dxyp^  . . .  Dz(Tn)  be  a 
sequence  of  expansion  steps  such  that  the  ith  step  is  applied  to  B,_1,  resulting 
in  B\  where  B  =  B°,  and  Bn  mentions  primitive  control  variables  only.  Since 
DEF*(j4)  is  sufficient,  such  an  expansion  sequence  exists. 

From  H-5  we  infer 

m(B)  =  ...  =  m(Bn).  (3.20) 

From  the  fact  that  Bn  is  primitive,  and  from  hypotheses  H-2  and  H-3  we  get:3 

m(Bn)  =  (Sn)“^|‘^r{fc(.)). 

Observe  that 

(  Rn\at( ■)>•/*«*■(•)  _ ((  d»\(')  \<»< 

V"  'in(h(-)),after(h(-))  ~  4(  )hn 

and  thus,  using  (3.20),  we  have 

m(fl)  =  m(B-)  =  ((B*)«))g.  (3.21) 

Given  (3.21),  our  goal  is  to  show 

(DE F*(R)  A  CNSR*(i?))  =>  (3.22) 

To  show  (3.22)  we  first  show  that  2?^  is  in  CNSR*(i?).  Then,  using 

Bhl)  6  cnsr*(22) 

we  will  argue  that 

(DEF*(i2)  A  CNSR*(ii))  =>  (Bn)[[y  (3.23) 

3We  use  the  notation  (•)  for  an  action  or  statement  name  in  any  control  variable.  For  example. 


(•<(«)  A  «<(6)  A  a/»er(T))-‘;^jJie.,Je)r<M.))  =  a<(fc(a))  A  ai{h(k))  A  after{h(T)) 
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Finally,  by  coverage  (3.19)  we  will  conclude  that  (3.22) — our  goal — holds.  The 
details  follow. 

Due  to  (3.6),  having  B  a  constraint  of  A  (i.e.,  B  €  CNSR*(A))  implies  that, 
for  some  T  €  Comps*(A),  B  is  a  constraint  of  T  (i.e.,  B  €  CNSR(T)).  From 
the  hypotheses  of  Theorem  2  (implements),  R  is  a  structural  refinement  of  A. 
Therefore,  by  Lemma  1,  we  get  h(T)  6  Comps*(R)  and  that  h(T )  is  a  structural 
refinement  of  T.  From  B  6  CNSr(T)  and  h(T)  a  structural  refinement  of  T,  we 
infer,  by  structure  (3.18),  that  J3j^  6  CNSR (h(T)).  Thus,  from 

h(T)  €  Comps*(R) 

and  (3.6)  we  infer 

Bhl)  e  CNSR*(i2).  (3.24) 

Now  we  show  that  from  (3.24)  and  DEF *(R)  it  is  possible  to  infer  (Z?")^,  thus 
proving  (3.23).  Recall  that  Dx(j.)  denotes  a  definition  in  DEF*(j4).  By  structural 
refinement,  h(Tj)  €  Comps*(R),  and  from  structure  (3.18)  we  can  infer  that 
Dz(h(Tj))  is  a  definition  in  DEF*(iZ).  So,  L>,(a(Ti))  •  •  •  Dx(h(Tn))  ^  ^  definitions 
in  DEF*(fZ),  and  they  can  be  used  to  derive  (B^)n  from  This  proves 

(DEF*(R)  A  CNSR*(R))  =>  (R^.))n-  (3.25) 

By  induction  on  n  one  can  prove 

(B')  il,  =  (*»)*.  (3.26) 

From  (3.25)  and  (3.26)  conclude  that  (3.23)  holds. 

Finafigr,  from  coverage  (3.19)  and  (3.23)  we  conclude  that  (3.22)  is  valid.  □ 


Lemma  6  (termination)  If  the  hypotheses  of  Theorem  2  (implements)  hold,  then 
the  formula 

(after(R)  =>•  0(after(R)))  =>  ( m(after(A ))  =>•  n(m(after(A)))) 

is  valid. 


Proof : 
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1  (after(R)  =>  D(after(R )))  =>  ( m(after(A ))  =>  n(m(after(A )))) 


1.1  after(R)  =>  □  (after(R)) 

assumption 

1.2  h(A)  =  R 

R  is  a  structural  refinement  of  A 

1.3  m(after(A))  =  after(h(A)) 

Hypothesis  H-3 

1.4  m(after(A ))  =  after(R) 

1.2,  1.3 

1.5  ml after(A))  =►  0(m(after(A))) 

TL  1.1,  1.4 

□ 


The  proof  of  Theorem  2  (implements)  has  two  major  steps.  In  the  first  one, 
the  above  lemmas  are  used  to  show 


( CAr  A  □ Ipo{R ))  =*  ™( CAa  A  □J/.0(y4)). 


In  the  second  step,  the  result  of  the  first  step  together  with  the  hypotheses  of 
the  theorem  and  the  fact  that  we  axe  dealing  with  proof  outlines,  are  used  to 
show  that  all  the  conditions  of  m-Implements  (2.12)  are  satisfied,  thus  PO(R) 
implements  (v).PO(A).  The  formal  proof  follows. 

Proof: 


1  ( CAr  A  Glpo(R))  =►  m(CAA  A 

1.1  ( CAr  A  □7/>o(rt)) 

!-2  Ipo(R)  =>  m(Ipo(A)) 

1.3  0//>o(«) 

1.4  am(IP0(A)) 

1.5  m(DEF*(A)) 


°Ipo(A)) 

assumption 
Lemma  3 
A  -elim  1.1 
TL  and  MP  1.3,  1.2 
H-4 
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1.6  m(cNSF*(A))  CAr  of  1.1  and  Lemma  5 

17  A h€AA(a(m(in(b))  =»  (m(in(b))[)m(after(b))))) 

1.7.1  For  every  b  e  Aa‘  h(b)  6  Comps*(R) 

R  is  a  structural  refinement  of  A 

1.7.2  For  every  b  €  Aa‘-  in(b)  =  at(b)  Equation  (3.3) 

1.7.3  For  every  b  6  Aa'.  m(in(&))  =  rn(at(b))  1.7.2  and  H-4 

1-7.4  A beAAW*(h(b))  =>  (in(h(b))U  after  (h(b))))) 

1.1,  Equation  (3.17) 

1-7.5  Ab€AA(°(m(at(b))  =►  (m(at(b))[)m(after(b))))) 

MP  Lemma  4,  1.7.4 

1.7.6  Ai€.4x(a(m(in(^))  =►  ( m(in(b))[}m(after(b )))))  1.7.5,  1.7.3 

1.8  D(after(R)  =>•  a(after(R)))  A  -elim  on  1.1 

1.9  D(m(after{A))  =*  Om((after(A))))  MP  Lemma  6,  1.8 

1.10  m(CAA)  A-incl  1.9,  1.7,  1.6,  1.5 


1.11  iti(CAa)  A  Qm(Ipo(A))  A-incl  1.10,  1.4 

1.12  m(CAA  A  OlP0{A) )  H-5  on  1.11 


So,  we  have  shown 


( CAr  A  BIpo(R))  =>  m(CAA  A 

which  is  condition  2c  of  m-Implements  (2.12).  Due  to  the  hypothesis  that 
Ne{R)  =  Ne(A ),  condition  1  of  m-Implements  (2.12)  is  satisfied.  The  hy¬ 
pothesis  that  m  is  a  function  and  that  it  satisfies  Hypothesis  H-l,  implies  that 
condition  2a  of  m-Implements  (2.12)  is  satisfied.  Finally,  as  we  argued  in  Sec¬ 
tion  3.2,  condition  2b  of  m-Implements  (2.12)  is  satisfied  as  well.  Thus,  by 
m-Implements  (2.12),  we  conclude  that  PO(R)  implements  (v).PO(A).  □ 
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3.4  Alternative  Mapping  for  Control  Variables 

In  Theorem  2  (implements)  we  made  a  choice  with  respect  to  the  definition  of 
m(at(a)),  for  any  action  a  E  A IH.  We  decided  that  as  long  as  control  is  inside 
h(a)  it  will  be  as  if  control  is  at  the  start  of  a.  This  decision  led  to  Hypothesis  H-2 
of  the  theorem, 

m(at(a))  =  tn(h(a )) 
m(after(a))  =  after(h(a)). 

This  decision  imposes  a  restriction  on  h(a) — as  long  as  a  state  s  of  the  imple¬ 
menting  program  satisfies  m(ti(a)),  it  must  satisfy  m(preP0^ # j(a) — so  that  F(s) 
satisfies  at(a)  =»  Vrtpo(H){a)-  order  to  satisfy  this  restriction,  it  may  be  neces¬ 
sary  to  introduce  auxiliary  variables.  These  are  used  to  record  state  information 
used  in  defining  m. 

Another  alternative  is  to  allow  the  mapping  of  some  control  points  inside  h(a) 
to  the  control  point  denoted  by  after(a).  Rather  than  stuttering  only  at(a),  as 
our  present  method  does,  we  must  now  stutter  after(a)  as  well.  In  fact,  we  must 
require  that  m(after(a))  =>  (m(after(a))li after (h(a)))  hold  for  every  behavior  of 
PO(L).  This  requirement,  in  turn,  implies  that  m(postp0^ff^(a))  must  hold  as 
long  as  m(after(a ))  does. 

Since  we  have  found  no  benefit  for  “switching  in  the  middle”  we  decided  to 
adopt  “switching  at  the  end”. 

3.5  A  Remark  on  Structural  Refinement 

The  significance  of  structural  refinement  is  that  it  formalizes  the  well  known 
process  of  program  derivation  by  step-wise  refinement.  Whenever  we  replace 
an  action  in  a  program  by  some  collection  of  actions,  the  resulting  program  is 
a  structural  refinement  of  the  original  one.  Not  only  does  using  structural  re¬ 
finement  simplify  showing  that  one  proof  outline  implements  another,  it  is  what 
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we  do  anyway  in  refining  programs.  Given  these  observations,  structural  refine¬ 
ment,  and  proof-outline  specifications  become  the  cornerstones  of  a  methodology 
for  deriving  multiple- server  implementations  of  a  service,  from  single- server  im¬ 
plementations  of  that  service.  The  methodology,  and  examples  axe  presented  in 
Chapter  4. 


Chapter  4 

Designing  Distributed 
Implementations  of  Services 


We  now  present  a  methodology  for  designing  multiple- server  implementations  of 
services.  The  methodology  is  based  on  constructing  a  structural  refinement  of  a 
proof  outline  for  a  single-server  implementation.  In  effect,  we  view  a  single-server 
implementation  of  a  service  as  an  abstraction  that  hides  details  of  a  multiple- 
server  implementation.  For  that  reason,  we  use  A  (abstract)  to  denote  a  single¬ 
server  implementation  and  R  (real)  to  denote  the  multiple-server  implementation. 

We  start  by  presenting  a  derivation  of  a  multiple-server  implementation  of 
a  mutual  exclusion  service.  We  then  explain  how  the  methods  in  this  example 
can  be  generalized  and  describe  a  methodology  that  embodies  the  generalization. 
We  conclude  this  chapter  with  the  derivation  of  multiple- server  implementation 
of  an  immutable-set  service. 

4.1  A  Mutual  Exclusion  Service 

Consider  the  problem  of  designing  a  mutual  exclusion  service  for  clients  ci, . . . ,  c„. 
The  program  of  each  client  has  a  critical  section  and  a  non-critical  section.  We 
must  devise  a  protocol  that  guarantees  at  most  one  client  executes  in  its  critical 
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PO(A):  {nxt  =  0  A  j  =  0  A  (J:  ^  tktp  <  g )} 

l<p<n 

cobegin  ||i<P<« 

PO(cp):  {tktp  <  nxt  <  g  A  1} 

Cp\  do  true  — ► 

{tktp  <  nxt  <  g  A  /} 

NCSp 

{tktp  <  nxt  <  g  A  7} 
getp:  (  g,tktp  :=  g +  l,g  ) 

{nxt  <  tktp  A  I  A  ( Xp  :  /\  tkt{  ^ 

enterp :  (  if  nxt  =  tktp  —*  skip  fi  ) 

{nxt  =  tktp  A  I  A  Xp} 

CSP 

{nxt  =  tktp  A  I  A  Xp) 
exitpi  nxt  :=  nxt  +  1 

{tktp  <  nxt  <  g  A  /} 
od 

{false} 

coend 

{fabe} 

Figure  4.1:  A  single-server  implementation  of  mutual  exclusion. 


section  at  any  time.  Denoting  the  critical  section  for  process  Cp  by  CSP,  an 
outline  of  such  a  protocol  was  given  in  Figure  1.1.  In  that  figure,  clients  use 
the  two  services:  tickets,  and  guard.  Therefore,  we  can  derive  a  distributed 
mutual  exclusion  service  by  constructing  multiple- server  implementations  of  these 
services.  Here  we  consider  only  the  guard  service. 

We  derive  a  multiple-server  implementation  of  the  guard  service,  by  using  a 
refinement  mapping  and  constructing  a  structural  refinement  of  a  single-server 
implementation  of  that  service. 

4.1.1  A  Single-Server  Implementation 

A  proof  outline  including  a  single-server  implementation  of  both  the  tickets  and 
guard  services  is  given  in  Figure  4.1.  In  it,  the  service  implementation  (client 
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stubs  and  server)  appears  in-line  in  client  programs.  This  is  done  to  avoid  reason¬ 
ing  in  terms  of  procedure  calls.  Actions  and  variables  that  become  visible  due  to 
this  in-line  expansion  Me  elements  of  the  service  implementation  and,  therefore, 
are  internal  elements  of  the  proof  outline  PO(A).  These  include  variables  g,  nxt , 
and  actions  getp,  enterp,  and  exitp. 

Proof  outline  PO(A)  can  be  derived  using  standard  techniques.  The  assertions 
in  PO(A)  must  be  strong  enough  to  prove  mutual  exclusion,  a  safety  property  that 
can  be  formalized  as: 


□  /\  ->(tn(CSp)  A  in(CSq))  (4.1) 

Viewing  PO(A)  as  a  specification,  we  prove  that  every  behavior  of  PO(A) 
satisfies  (4.1)  by  first  showing  that  Ipo(A)  =>  Al<p,q<n,pqtq  ~’(wi(CSj>)  A  m{CSq)) 
is  valid,  and  then,  using  validity  of  Inv(PO(S ))  (3.8)  which  asserts  °Ipo(A), 
conclude  that  every  behavior  of  PO(A)  satisfies  (4.1). 

The  proof  outline  PO(A)  is  valid.  Thus  every  execution  of  A,  if  started  at 
a  state  that  satisfies  Ipo(A)i  “  a  behavior  of  PO(A),  implying  that  every  such 
execution  satisfies  (4.1). 

4.1.2  Deriving  Multiple-Server  Implementations 

Proof  outline  PO(A)  above  is  in  terms  of  single-server  implementations  of  both 
the  tickets  and  guard  services.  Suppose  that  we  desire  a  multiple-server  imple¬ 
mentation  of  the  guard  service.  Let  there  be  k  servers,  each  a  replica  of  the 
single  s«ver  that  maintained  nxt  in  A.  Thus,  our  goal  is  to  derive  an  implemen¬ 
tation  of  the  guard  service  that  is  based  on  nxt i, . . . ,  nxt*  instead  of  being  based 
on  nxt .  To  achieve  this  goal,  we  design  an  implementation  for  the  specification 
( v).PO(A ),  where  V  is  a  list  of  the  elements  of  the  set 

{nxt}  (J  {at(enterr),  aftcr(enterp),  at(exitp),  after(exitp),  enterp,  exitp}. 

1  <J><» 
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Observe  that  ( V).PO(A )  explicitly  restricts  potential  implementations  to  change 
only  server  related  elements. 

To  design  an  implementation  for  (u).PO(A),  we  postulate  a  mapping  mRA 
that  defines  nxt  in  terms  of  nxt\, . . . ,  nxt*  and  use  mRA  to  derive  a  proof  outline 
PO(R)  that  satisfies  the  hypotheses  of  Theorem  2  (implements).  This  allows 
the  conclusion  that  PO(R)  implements  ( V).PO(A ),  which,  in  turn,  implies  that 
PO(R)  satisfies  (4.1).  Moreover,  if  PO(R)  is  valid,  then  we  can  conclude  that  R, 
when  started  in  a  state  that  satisfies  Ipo(R )>  also  satisfies  (4.1). 

When  using  Theorem  2  (implements)  for  proving  that  one  proof  outline  im¬ 
plements  another,  candidate  refinement  mappings  are  constrained  by  hypotheses 
H-l-H-6.  In  fact,  all  that  is  necessary  in  defining  the  refinement  mapping  is  a 
mapping  of  internal  variables  that  are  not  also  control  variables  because  H-l-H-5 
define  the  mapping  for  control  variables.  For  the  single-server  implementation  of 
the  guard  service,  there  is  only  one  such  variable:  nxt. 

In  Section  1.2  (Equation  (1.1))  we  presented  a  mapping  for  nxt  that  required 
keeping  nxt\, . . . ,  nxt*  equal.  Another  possible  mapping  for  nxt  is  obtained  by 
inventing  a  variable  hotCopy  and  defining  mRj ^(nxt)  to  equal  nxt  HotCopy  The 
disadvantage  of  using  this  refinement  mapping  is  that  as  long  as  hotCopy  does 
not  change,  the  service  is  being  implemented  in  terms  of  a  single  server — the 
one  indicated  by  hotCopy.  And,  to  allow  hotCopy  to  change,  requires  another 
protocol. 

Yet  another  mapping  for  nxt  is 

mRA(nxt)  =  max  (nxt i).  (4.2) 

This  mapping  defines  the  value  of  nxt  to  be  the  maximum  of  nx<i, . . . ,  nxt*. 
From  an  engineering  point  of  view,  (4.2)  is  attractive  because  it  is  defined  in 
any  state  and  does  not  require  that  updates  to  nxti, . . .  ,nxt*  be  coordinated. 
Choosing  a  refinement  mapping  reflects  the  experience,  ingenuity,  and  intuition 
of  the  designer;  different  choices  can  lead  to  implementation  that  differ  in  their 
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PO(R):  { max(nx*,)  =  OAj  =  Oa(/:  /\  tktp  <  g)} 

-  l<p<n 

cobegin  ||i<P<„ 

POicp):  {tktp  <  max(nxti)  <  g  A  7} 

Cp\  do  true  -* 

{ tktp  <  max  (nxti)  <  g  A  7} 

NCSp 

{tktp  <  max(nxtj)  <  g  A  7} 

getp:  (  g,tktp  :=  g  +  l,g  ) 

{j ™f£k(nxtt)  <  tktv  A  7  A  (Xp  :  /\  tkt,  ^  tktp)} 
— 

enterp :  (  if  nxt  =  tktp  — *■  skip  fi  ) 

{  max(nxt/)  =  tktp  A  I  A  Xp} 

CSp~ 

{  max  (nxti)  =  tkt „  A  1  A 
l<l<kx  '  v  Pl 

exitp.  nxt  :=  nxt  +  1 


{tktp  <  max  (nxti)  <jA/} 


od 

{/oZsc} 

coend 

{false} 


Figure  4.2:  Translated  assertions. 


performance  costs. 

Having  selected  as  a  candidate  refinement  mapping,  our  goal  is  to  derive 
a  proof  outline  PO{R)  that  is  a  structural  refinement  of  (u).PO(A),  and  for  which 
the  hypotheses  of  Theorem  2  (implements)  are  satisfied. 

We  start  by  reformulating  the  assertions  in  PO(A)  as  assertions  with  tree 
variables  from  N(R),  such  that  an  assertion  Q  in  PO(A)  is  reformulated  rnRA(Q)- 
Doing  this  guarantees  that  for  every  external  control  point  (i.e.,  a  control  point 
belonging  to  an  external  action)  hypothesis  H-6  is  satisfied.  The  resulting  (not 
necessarily  valid)  proof  outline,  PO(R!),  is  shown  in  Figure  4.2. 

In  PO(R!),  the  triples  for  internal  actions  enterp,  exitp  are  not  valid — the 
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actions  modify  nxt  and  the  assertions  are  in  terms  of  nxt\, . . . ,  nxt^.  If  we  view 
PO(R *)  as  a  specification,  the  fact  that  it  is  not  valid  is  not  an  impediment 
to  proving  that  PO{R!)  implements  (t J).PO(A).  However,  proving  that  PO{R') 
implements  (v).PO(A)  will  not  allow  us  to  conclude  anything  about  R!  itself 
unless  PO(R')  is  valid.  So,  validity  of  PCXR!)  is  essential  for  our  goal  of  deriving 
a  multiple-server  implementation  of  the  mutual  exclusion  service.  Note  also  that 
restoring  validity  of  PO(R!)  coincides  with  the  goal  of  deriving  guard  service 
implementation  in  terms  of  nxt\, . . .  ,nxt^ — we  want  to  replace  actions  enter p 
and  exitp  by  programs  that  use  nxt\, . . . ,  nxt *  instead  of  nxt. 

In  the  following,  h(a),  h'(a),  etc.,  denote  candidate  replacement  programs  for 
an  action  a  €  -^po(A)-  Since  a  is  an  atomic  action,  any  statement  is  a  structural 
refinement  of  a.  Define  PO(h(a))  to  be  a  proof  outline  of  h(a). 

Derivation  of  PO(h(a))  is  driven  by  two  requirements.  First,  to  satisfy  Hy¬ 
pothesis  H-6  of  Theorem  2,  PO(h(a))  must  satisfy 

W(«))  A  *n(M«0)  =►  PrePO{R')(a)-  (4-3) 

Second,  in  order  to  restore  validity  in  PO(R!),  proof  outline  PO(h(a))  must  also 
satisfy 

PrePO(R')(a )  =>  pre(PO(h(a ))) 

(4.4) 

post(PO(h(a)))  =>  postPO{RI)(a). 

In  light  of  this,  we  now  present  several  possible  structural  refinements  for  actions 
enterf  and  exitp. 

Refining  enterp 

A  first  approximation  for  the  refinement  of  enterp  is  given  in  Figure  4.3.  This 
proof  outline  is  obtained  by  observing  that  the  difference  between  the  precondi¬ 
tion  and  postcondition  of  enter p  in  PO(R!)  is  that  the  postcondition  ensures 
that  states  satisfy  both  the  precondition  and  maxi</<*(n:rtj)  =  tktp}  The 

lBy  definition,  execution  of  {  if  maxi<K*(nxtf)=  tktp  — *  skip  fi  )  is  delayed  until  the 
condition  maxi <K*(nx</)=  lktp  holds. 
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PO(h(enterp)):  {  max (nxtj)  <  tktp  A  I  A  ( Xp  :  A  tkt\  ^  tfctp)} 

h(enterp ):  {  if  maxi</<t(ni</)=  tJfctp  — ♦  skip  fi  ) 

{  max(nifi)  =  tktp  A  /  A  Xp } 

\<l<k  y  Pl 

Figure  4.3:  A  first  step  in  refining  enterp. 

reader  can  verify  that  (4.3)  and  (4.4)  are  both  satisfied  by  this  proof  outline. 
Thus,  PO(h(enterp))  is  (theoretically)  an  acceptable  refinement  of  enterp.  How¬ 
ever,  h(enterp)  specifies  am  action  that  calculates  the  maximum  of  nxt i, . . . ,  nxt ^ 
atomically,  which,  from  a  practical  point  of  view,  is  an  expensive  operation  to 
implement.  This  suggests  that  we  look  further. 

The  atomicity  requirement  of  h(enterp)  can  be  relaxed.  The  insight  leading  to 
that  relaxation  is  obtained  by  reformulating  pre(h(enterp))  and  post(h(enterp)). 
By  definition,  maxi<;<*(nxt/)  <  tktp  in  the  precondition  is  equivalent  to 

(  A  ( nxtl  ^  tktp))-  (4-5) 

1  <l<k 

Similarly,  maxi<j<*(nx</)  =  t':tp  in  the  postcondition  is  equivalent  to 

(  A  (ni*/  ^  tkti >))  A  (  V  ( nxtl  —  tktp))-  (4.6) 

i</<*  1<K* 

Observe  that  (4.6)  results  from  strengthening  (4.5)  with  the  conjunct 

Y  ( nxti  =  tktp). 
l  </<* 

A  proof  outline  containing  an  if  statement  to  implement  this  strengthening  is 
given  in  Figure  4.4.  Although  the  action  in  Figure  4.4  does  not  relax  the  atom¬ 
icity  requirement,  it  can  be  implemented  using  a  cobegin  statement  as  shown 
in  Figure  4.5.  This  cobegin  terminates  only  if  nxti, . . .  ,  nit*  are  incremented 
whenever  any  one  of  them  is,  and  results  in  an  unnecessary  delay  for  enterp.  To 
avoid  this  unnecessary  delay,  we  introduce  a  variable  donep  for  every  client  cp, 
that  marks  the  server  instance  j  for  which  nxtj  =  tktp  holds.  One  option  is  to 
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{  /\  ( nit/  <  tktv )  A  I  A  Xp } 
l<l<k 

(  if  Vi<Ki(ni*/  =  tktp)  — ►  skip  fi  ) 

{  /\  ( nxt/  <  tktp)  A  Y  ( nit/  =  tktp)  A  I  A  Xp} 

l</<*  l<Kfc 

Figure  4.4:  A  second  step  in  refining  enterf. 


{  f\  ( nit/  <  tktp)  A  /  A  Xp} 
l</<* 

cobegin  ||i<,<* 

{  ^  (nit/  <  tktp)  A  /  A  Xp} 
l<l<fc 

if  nxtj  =  fJfctp  — ♦  skip  fi 
{  ^  ( nxti  <  tfctp)  A  nit;-  =  tktp  A  /  A  Xp} 
1<K* 

coend 

{  (nxti  <  tktp)  A  Y  (nit/  =  tfctp)  A  /  A  Xp} 
l</<*  l</<k 


Figure  4.5:  A  third  step  in  refining  enferp. 
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PO(h!  (enter  p))\  {  f\  ( nxt(  <  tktp )  A  I  A  Xp} 
l  <l<k 

donep  :=  0 

{  /\  ( nxt{  <  tktp)  A  I  A  Xp  A  Dp} 
l  <l<k 

cobegin  ||  i<j<i 

{(Lp  :  J\  ( nxtt  <  tktp))  A  I A  Xp  A  Dp} 
\<l<k 

(  if  nxtj  =  tktp  A  donep  =  0  — ►  donep  :=  j 
|]  donep  ^  0  — ►  skip 

[Lp  A  ( Ep  :  Vl <l<k(nxti  =  tktp))  A 

I  A  Xp  A  Dp  A  donep  0} 

coend 

[Lp  A  Ep  A  I A  Xp  A  Dp  A  donep  ^  0} 

Figure  4.6:  A  cobegin  refinement  of  enterp. 


implement  donep  as  a  Boolean  that  is  initialized  to  false  upon  entry  to  the  cobe¬ 
gin  and  set  to  true  once  such  a  server  instance  is  found.  More  useful,  though,  is 
to  store  in  donep  the  identity  of  the  server  instance  j  for  which  nxtj  =  tktp  (i.e., 
the  server  instance  that  actually  gave  permission  to  enter  the  critical  section). 
To  do  this,  the  following  is  used  in  h(enterp ): 

Dp\  0  <  donep  <  k  A  donep  ^0=>  nxtjonep  =  tktp. 

It  is  straightforward  to  verify  that  (Dp  A  donep  ^  0)  =>  Vi</<*(nxiJ  =  tktp).  The 
resulting  cobegin  refinement  of  enterp  is  given  in  Figure  4.6.  The  reader  may 
verify  PO(h! (enter p))  satisfies  both  (4.3)  and  (4.4),  and  that  it  is  valid. 

Refining  exitp 

Action  exitp  of  Figure  4.2  must  be  replaced  by  a  program  that  increments 
maxi</<i(nztj).  One  method  is  to  increment  each  of  nxti,nxt2, . . .  ,nxfy.  This, 
however,  is  inefficient.  Another  method  is  to  find  a  server  instance  j  for  which 
nxtj  =  maxi</<*(nxt/)  holds,  and  increment  nxtj.  This  can  be  described  by 

h(exitp):  Find  j  such  that  nxtj  =  maxi</<*(nxt/)  and  increment  nxtj. 
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PO(h(exitp )):  {nx^onep  =  max  (nxtj)  =  tktp  A  /  A  Xp  A  Dp  A  donep  ^  0} 

KZtdontp  :=  nx^donep  "t"  1 

{tktp  <  max  (nxtj)  <j  A  /} 

Figure  4.7:  Refining  exitp. 

However,  given  PO(h'(enterp ))  of  Figure  4.6,  calculating  maxi<j<*(nxfj)  and 
searching  for  the  server  j  for  which  nxtj  =  max1</<t(nxt/)  holds  is  not  necessary. 
Due  to  the  conjuncts  Dp  and  donep  ^  0  in  post(PO(h' (enter p))),  we  conclude 
that  nxtjotiep  =  maxj <j<*(nxtj)  holds,  and  so  incrementing  nxtjonep ,  as  shown  in 
Figure  4.7,  is  all  that  is  needed.  It  is  straightforward  to  verify  that  PO(h(exitp)) 
is  valid,  and  that  it  satisfies  both  (4.3)  and  (4.4). 

A  complete  multiple-server  implementation 

A  complete  specification  PO(R )  of  a  multiple-server  implementation  results  Rom 
replacing  actions  enter p  and  exitp  of  Figure  4.2  by  their  proof  outline  refinements, 
PO{h! (enterp))  of  Figure  4.6  and  PO{h(exitp))  of  Figure  4.7.  The  proof  outline 
PO(R )  is  presented  in  Figure  4.8. 

Proof  outline  PO(R)  of  Figure  4.8  implements  (v).PO(A).  This  follows  from 
the  fact  that  due  to  the  way  we  constructed  R  from  A ,  PO(R)  is  a  structural 
refinement  of  (v).PO(A),  and  from  the  fact  that  proof  outlines  PO(h' (enter p)) 
and  PO(h(exitp))  satisfy  both  (4.3)  and  (4.4). 

The  multiple-server  implementation  of  the  mutual  exclusion  service  given  in 
PO(R)  ku  a  problem.  Once  some  server  variable  nxtj  is  incremented  in  h(exitp), 
this  variable  determines  the  value  of  maxi</<*(nx#/)  thereafter.  Thus,  some  of  the 
disadvantages  of  a  single-server  implementation  are  retained.  This  problem  can 
be  solved  by  introducing  another  program,  consisting  completely  of  internal  vari¬ 
ables  and  actions,  that  repeatedly  (“in  the  background”)  updates  nxt\, . . .  ,nxt* 
to  follow  maxi</<jfc(nxtj).  An  outline  of  such  a  program  is  given  in  Figure  4.9. 

A  true  multiple-server  implementation  of  the  mutual  exclusion  service  can 


PO(R):  {(P  :  max(nxti)  =  0  A  <7  =  0)  A  (J  :  f\  tkt,  <  <7)} 

-  l<p<n 

cobegin  |Ji<p<» 

{tkt,  <  max(nxtj)  <  g  A  1} 

c ,:  do  true  — ► 

NCS, 

{tkt,  <  m ax(nxt/)  <  g  A  1} 

get,-.  <  g,  tkt,  :=  g  +  l,g  ) 

{  /\  (nxti  <  tkt,)  A  I  A  ( X ,  :  /\  tktt  ±  tkt,)} 

l</<*  / /j> 

h' (enter,):  done,  :=  0 

{( L ,  :  (nxti  <  tkt,))  A  I A  X,  A  D,} 

1  </<* 

cobeginJl!^-^  {L,  A  I A  X,  A  D,} 

{  if  nxtj  =  tkt,  A  done,  =  0  — ►  done ,  j 

(]  done,  ^  0  — ►  skip 
fi  )  {Ip  A  (E,  :  Vi <l<k(nxt{  =  tkt,))  A 

I  A  X,  A  D ,  A  done,  0} 

coend 

{  m ax  (nzt/)  =  tkt,  A  I  AX,  A  D,  A  done,  ^  0} 


{  max  (nxtf)  =  tkt,  A  I  AX,  A  D,  A  done,  0} 
h(exit,):  {nxtdonep  =  mw(nit,)  =  tkt,  A  I  A  X,} 
nxtdontp  nxtd 

ontf  +  1 

{tkt,  <  m ax(nxti)  <  g  A  /} 

od  {false} 
coend  {false} 

Figure  4.8:  A  distributed  mutual  exclusion. 


in.  (A  nxt{  <  max  (nxt/))  A  (  \J  nxt{  =  max(nxf/))} 
l<i<jfc  1-/-*  i<,<* 

PO{bkgmd ):  cobegin  ||i<r<* 

{/!}  "" 

do  true  — ►  nxtf  :=  max(nxtr,  nxti) 

{H} 

j]  true  — *■  nxt,  :=  max(  nxtr,  nxt2) 

{/!} 

{/!} 

j]  true  — »  nxt,  :=  max(nxtr,  nxt*) 

U1} 

od 

{/a/se} 

coend 

{/alse} 

Figure  4.9:  A  background  update  of  server’s  state  (gossip). 


PO(TR):  {  max  (nxt/)  =  0  A  j  =  0)  A  tktv  <  5} 

1-,-fc  l<P<n 

cobegin 

PO{  R) 

II 

PO{bkgmd ) 
coend 
{/olse} 

Figure  4.10:  A  multiple-server  implementation  of  the  mutual  exclusion  service. 


be  constructed  by  a  concurrent  composition  of  PO(R)  and  PO(bkgmd),  resulting 
in  PO(TR)  of  Figure  4.10.  The  proof  that  PO(TR)  implements  PO(R)  is 
straightforward.  It  is  based  on  classifying  all  variables  and  actions  of  PO{R)  as 
externals,  and  classifying  all  variables  and  actions  in  PO(bkgmd)  as  internals. 
With  this  classification,  the  actual  proof  of  PO{TR)  implements  PO(R )  is  based 
on  (3.9).  In  [LL86],  the  actions  of  programs  like  PO{bkgmd)  of  Figure  4.9  axe 
described  as  “gossip”. 

Finally,  using  the  cobegin  rule  of  [Sch],  it  is  straightforward  to  show  that 
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P0{  TR)  is  valid.  This  allows  concluding  that  executions  of  TR,  when  started  in 
a  state  that  satisfies  IP0(rR),  are  all  behaviors  of  PO{  TR)  and,  thus,  satisfy  (4.1). 

4.2  A  Methodology  for  Designing  Distributed 
Services 

The  derivation  of  the  distributed  mutual-exclusion  algorithm  in  Section  4.1,  illus¬ 
trates  a  general  methodology  for  designing  distributed  services.  The  methodology 
involves  three  steps: 

1.  Design  a  single-server  implementation  of  the  service  with  a  proof  outline 
PO(A).  Let  U  be  the  list  of  server  variables  and  actions  and  (u).PO(A)  be 
the  resulting  specification.  Internal  actions  of  ( V).PO(A )  are  assumed  to 
be  atomic. 

2.  Fix  a  concrete  state  space  E*  (i.e.,  NE(R),NI(R)),  and  select  mRA ,  a 
candidate  refinement  mapping.  Define  mm  so  that  hypotheses  H-l-H-5  of 
Theorem  2  (implements)  are  satisfied. 

3.  Use  mRA  to  obtain  PO(R) — the  multiple-server  implementation — as  fol¬ 
lows: 

(a)  Translate  every  assertion  Q  in  PO(A)  to  the  expression  mRA(Q). 

Let  PO(R!)  denote  the  resulting  (not  necessarily  valid)  proof  outline. 

Note,  due  to  this  translation,  for  every  T  €  Comps*  (R),  the  expres- 

aions 


both  hold. 


prtpo(R')(T )  =  ™RA(prePo(A)(T)) 
PoatPO(R')(T )  =  rnRA(postPO(A)(T)) 
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(b)  Replace  in  PO(R!)  every  internal  action  a  by  a  proof  outline  PO(h(a)) 
that  satisfies 

PrePO(R>)(a )  =»  Pre(PO(h(a)))  ^  ^ 

post(PO(h(a)))  =►  postPO(R,)(a) 

and  also  satisfies 

(in(h(a))  A  IP0(h(a)))  =►  Prepo(R')(H «))•  (4-8) 

(c)  Ensure  that  for  every  state  s  in  every  behavior  of  the  resulting  proof 

outline  PO(R),  and  for  every  name  x  €  N(A),  the  value  s(mRA(x))  is 
unique.  □ 

This  methodology  guarantees  that  PO(R )  implements  (v).PO(A),  as  shown  by 
the  following  theorem. 

Theorem  7  If  PO(R)  is  derived  from  (jj).PO(A)  by  using  the  methodology  above, 
then  PO(R)  implements  (v).PO(A). 

Proof :  The  proof  is  based  on  showing  that  the  hypotheses  of  Theorem  2  (im¬ 

plements)  are  satisfied. 

First,  we  show  that  PO(R)  is  a  structural  refinement  of  (v).PO(A).  It  suffices 
to  show  that  (i)  R  is  a  structural  refinement  of  A  and  (ii)  that  for  every  external 
action  a  of  A ,  its  structural  refinement  h(a)  is  a  itself  (see  Structural  refinement 
of  proof  outlines  (3.11)).  To  show  (i),  recall  that  any  statement  is  a  structural 
refinement  of  an  atomic  action.  Since  server  invocations  in  A  are  atomic  (due 
to  step  1)  and,  by  our  methodology,  R  is  obtained  from  A  by  replacing  server 
invocations  by  statements  and  leaving  all  the  rest  unchanged,  R  is  a  structural 
refinement  of  A.  Requirement  (ii)  follows  from  the  fact  that  only  the  internal 
actions  of  A — server  invocations — are  changed  in  order  to  obtain  R ,  thus,  for  any 
external  action  o,  h(a)  =  a.  Using  Structural  refinement  of  proof  outlines  (3.11), 
from  (i)  and  (ii)  we  conclude  that  PO(R)  is  a  structural  refinement  of  (v).PO(A). 
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Second,  we  must  show  that  refinement  mapping  mRA  is  well-defined.  Since  in 
step  (3)  of  our  methodology  PO(R )  was  derived  from  PO(A)  using  a  refinement 
mapping,  and  the  mapping  is  uniquely  defined  for  every  state  of  PO(R )  and  every 
variable  name  of  PO(A)  (step  3c  of  the  methodology),  this  follows  trivially. 

Third,  we  must  show  that  hypotheses  H-l  through  H-6  of  Theorem  2  (im¬ 
plements)  hold.  By  step  2  of  our  methodology,  hypotheses  H-l  through  H-5  are 
satisfied.  We  now  show  that  hypothesis  H-6  is  also  satisfied. 

1  Consider  any  a  €  Aa 


2  ( Ipo(R )  A  mRA(at(a)))  =$►  mRA(prePO{A)(a)) 

2.1  (ho(R)  A  rnRA(at(a ))) 

2.2  a  £  A%V  a  £  AJa 

2.3  a  e  A$  =>  rnRA{preP0(A)(a)) 

2.3.1  a  €  A% 

2.3.2  mRA(prepo{A)(a)) 

2.3.2.1  at(a)  €  NE(A) 


assumption 

1 


assumption 


2.3.1 


2. 3.2.2  mRA(at(a))  =  at(a)  H-l,  2.3.2.1 

2.3.2. 3  Ipc^R)  A  at(a )  A  -incl  on  2. 3. 2. 2,  2.1 

2. 3.2.4  prtpo(R)(a)  2. 3. 2. 3 

2. 3. 2. 5  mRA(prep0^(a))  2. 3. 2.4,  step  3a  of  the  methodology. 

2.3.3  a  6  A%  =►  mR^prtpo^a))  2.3.1,  2.3.2 

2.4  o  6  i  =►  miu(p"p0{>1)(a)) 

2.4.1  a  €  A!a  assumption 

2.4.2  mflA(pre,>o(A)(a)) 

2.4.2. 1  at(a)  6  JVJ(A) 

2. 4.2. 2  mRA(at(a))  =  in(h(a)) 


2.4.1 
2. 4. 2.1,  H-2 


'  A 
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2.4.2.3  Ipo^R)  A  in(h(a)) 

2.4.2.4  IPO(R)  =*  Ipo(h(a)) 
2  4.2.5  Ipo(h(a)) 


A  -incl  2. 4. 2. 2,  2.1 
step  3b  of  the  methodology. 

MP  2.1,  2. 4. 2. 4 


2.4. 2.6  Ipo(ii(a))  A  »n(h(a))  A  -incl  2. 4. 2. 3,  2. 4. 2. 5 

2.4.2. 7  prePO(R,}(h(a))  MP  Equation  4.8,  2. 4. 2. 6 

2.4.2.8  mRA(Prepo(A)(a ))  step  3a  of  the  methodology,  2.4.2. 7 

2.4.3  .  €  A'a  =*  mRA(Pr^po(A)(a))  2.4.1,  2.4.2 

2.5  mRA(preP0(A)(a ))  V-ehm  2.2,  2.3,  2.4 

3  A *eAA((Ipo{R)  A  rnRA(at(a)))  =>  1,  2 

4  A  mRA(after(A)))  =>  mRA(postp0(A)(A)) 


4-l  Ipo(R)  A  m RA{after{A))  assumption 

4.2  mRA(po3tp0{A)(A)) 


4.2.1  mRA(after{A )) 

A  -elim  4.1 

4.2.2  after (R) 

see  Lemma  6 

4.2.3  postp0(Rj(R) 

MP  4.1,  4.2.2 

4.2.4  rnRA(postPO{A)(A)) 

4.2.3,  and  3a  of  the  methodology. 

4-3  U/>o(it)  A  m/tA(«^cr(A)))  =►  mA4(post^A)(A))  4.1,  4.2 


5  By  3  and  4  conclude 


A *eAA((Ipo(R)  A  mRA(at(a)))  =►  m^(prep0(/t)(a))) 
A  mRA(^r(A))  =>  mRA(postp0{A)(A)) 


a 


By  ensuring  that  PO(R)  is  valid,  we  can  also  conclude  that  executions  of  the 
resulting  program  R,  when  started  in  a  state  satisfying  a  given  initial  condition, 
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axe  ail  behaviors  of  (V).PO(A).  In  fact,  we  conjecture  that  if  PO(A)  is  valid, 
PO(R)  is  a  structural  refinement  of  PO(A),  and  the  proof  outlines  replacing 
the  internal  actions  of  (F).PO(A)  are  valid  and  mutually  interference-free,  then 
PO(R)  will  be  valid. 

4.2.1  Performance 

A  program  R  that  results  from  applying  our  methodology  is  guaranteed  to  satisfy 
the  specification,  but  is  not  guaranteed  to  be  efficient.  In  general,  the  coarser 
the  atomicity  of  operations,  and  the  larger  the  number  of  servers  that  must  be 
involved  in  performing  an  operation,  the  worse  will  be  the  performance  of  the 
multiple- server  implementation.  Two  factors  contribute  significantly  to  the  per¬ 
formance  of  a  multiple-server  implementation  that  is  obtained  using  our  method¬ 
ology.  The  first  is  the  choice  of  refinement  mapping.  In  Chapter  i,  we  used 

Inxti  if  true 

. 

nxt»  if  true 

as  a  refinement  mapping.  The  resulting  implementation  (see  Figure  1.5)  involved 
updating  all  servers  atomically.  Implementations  for  the  same  problem  that  were 
presented  in  this  chapter,  are  all  based  on  a  different  refinement  mapping 

nxt  =  max(nxti). 
l  <l<k 

This  minnnii  lit  mapping  did  not  impose  such  an  atomicity  requirement.  So,  per- 
formaa—  iwaa  can  be  addressed  by  considering  different  refinement  mappings. 

The  Monad  factor  affecting  performance  is  the  original  specification  (t l).PO{A) 
itself.  The  weaker  the  specification,  the  less  it  constrains  an  implementation. 
Sometimes,  in  designing  a  single-server  implementation,  one  does  not  realize  that 
certain  assertions  in  PO(A)  are  stronger  than  necessary.  However,  when  using 
our  methodology  for  deriving  the  multiple-server  implementation,  such  strong  as¬ 
sertions  can  lead  to  an  implementation  that  requires  large  atomic  actions.  When 
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this  happens,  one  should  refer  back  to  PO(A)  and  check  whether  it  is  possible 
to  weaken  assertions  that  seem  to  induce  the  observed  performance  problems. 
We  illustrate  these  ideas  about  performance  in  the  next  section,  where  we  de¬ 
rive  a  distributed  implementation  of  a  set  service  and  show  how  a  change  in  the 
specification  can  have  a  dramatic  effect  on  an  implementation. 

4.3  A  Distributed  Set 

Desired  is  a  multiple-server  implementation  of  a  monotonic-set  service  that  sup¬ 
ports  operations  insert  and  member.  We  start  by  specifying  a  single-server  im¬ 
plementation  that  maintainr.  a  set  S.  Then,  we  derive  an  implementation  of 
5  that  uses  a  collection  of  k  server  instances  where  server-instance  j  maintains 
set-instance  Sj. 

4.3.1  A  Single-Server  Implementation 

The  server  maintains  a  set  S  and  provides  two  operations,  which  can  be  specified 
as  proof  outlines: 

{psu{r)}  irisert(x)  {P}  ^ 

{true}  mem6er(x,y)  {y  =  x  6  5} 

4.3.2  A  Multiple-Server  Implementation 

To  derive  a  multiple-server  implementation  of  the  set  service,  we  define  a  refine¬ 
ment  mapping  that  defines  set  5  in  terms  of  set  instances  Si,...,Sfc.  Several 
different  mappings  are  possible,  each  producing  a  different  multiple-server  imple¬ 
mentation.  We  use  m,  m',  etc.,  to  denote  the  mappings. 

One  such  mapping  is 

m(S)  =  [J  S,.  (4.10) 

l<l<k 

It  is  fairly  easy  to  see  that  m  induces  an  inexpensive  update — an  element  that  is 
inserted  in  any  one  of  the  set  instances  is  considered  to  be  in  the  set.  However, 
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this  mapping  does  result  in  an  expensive  membership  operation.  In  order  to  test 
for  membership,  all  set  instances  might  have  to  be  tested. 

Another  possible  mapping  is 

m'(5)=  f|  Si-  (4-11) 

l  <i<k 

In  contrast  to  mapping  m  (4.10),  m'  causes  updates  to  be  expensive — an  element 
must  be  inserted  in  all  set  instances  before  it  is  considered  to  be  in  the  set.  The 
test  for  membership  when  m'  is  used,  also  is  expensive.  In  the  worst  case  (when 
the  tested  element  is  a  member  of  the  set )  all  set  instances  must  be  tested. 

In  the  following  sections  we  derive  a  multiple-server  implementation  of  the 
set  service  that  is  driven  by  m  (4.10). 


Implementing  insert 


We  start  by  translating  the  assertions  in  the  specification  of  *nsert(i).  For  an 
assertion  P,  m(P)  =  P^l<Kkst-  I*  is  straightforward  to  verify  that 

*}' 

For  notations!  convenience,  let  Q  denote  P^ ^  thus  the  first  outline  is 

>”»«•*(*)  (<?}•  (4-12) 


In  order  to  make  (4.12)  valid,  we  must  replace  the  action  insert(x)  by  actions 
that  invoke  insert j  operations  of  server  instances  1, . . . ,  k.  Since  5  is  union  of 
Sj’s,  and  assuming  that  the  semantics  of  an  insert  j  operation  is  given  by 

{*sju{ ,})  i™ert j{x)  {P}, 


invoking  a  single  insert  j  will  suffice.  Formally,  since  for  any  S:  appears  in  Q 
only  as  part  of  Ui</<ft5;,  and  since  set  union  is  associative,  we  have 

<KkSl  _  nSj 


This  observation  leads  to  the  program  in  Figure  4.11,  which  is  a  refinement  of 
insert  that  nondeterministically  selects  a  server  instance  j  and  invokes  insert j. 
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m  Ui<i<*s‘ 

if  fli<7<t  true 

insertj(x) 

{Q} 

fi 

{Q} 

Figure  4.11:  A  multiple- server  implementation  of  insert. 
Implementing  member 

Translating  the  assertions  in  the  specification  of  member  (4.9)  we  get  the  triple 

{true}  member(x,  y)  {y  =  x  £  Uj</<t5/}.  (4.13) 

Again,  for  validity  we  must  replace  member(x,y)  in  (4.13)  by  operations  on  the 
server  instances.  Assume  that  each  server  j  provides  an  operation  member j  with 
the  following  semantics 

{true}  member j{x,y)  {y  =  x  £  Sj}.  (414) 

One  possible  approach  for  refining  member  is  to  use  Boolean  variables  yj , . . . ,  y* 
to  collect  the  results  from  the  servers  and  compute  y  as  a  function  of  the  yj's. 
Although  correct,  this  is  expensive.  Once  any  of  the  y;’s  becomes  true ,  x  £ 
Ui <l<kSi  holds.  Still,  in  order  to  assert  x  £  Ui</<*5/,  the  values  of  all  yj's  are 
needed.  The  program  segment  in  Figure  4.12  expresses  this  idea. 

A  weaker  specification  for  member 

Suppose  the  specification  of  member  is  weakened  to  be 

{true}  member(x,y)  {y  =>■  x  6  5}.  (415) 

To  obtain  a  multiple- server  implementation  we  use  m  to  tran..  .ate  the  assertions 
in  (4.15).  We  get  the  proof  outline 


{true}  member(x,y)  [y  =>  x  £  Uj</<*S/}. 


(4-16) 


1 
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{true} 

Vi ,---,Vk  ■=  false,..., false 
cobegin  ||i<j<* 

{^2/j} 

^  ^(Vi <i^j<kyi)  -* 

hyj ) 

member j(x,  yj) 

{yj  =  x  €  S;  } 

fl  — 1 ► 

{-'yj  a  V  yi } 

i  <¥j<* 

skip 

hvj  a  v  yi} 

fi 

{yj  =  x  e  Sj  V  {^yj  A  V  Vl )} 

i  <¥i<fc 

coend 

{  A  (w  =  x  €  V  (-y;  A  V  y/))} 

i</<* 

{(V  yi)  = x  6  ui<i<*5i} 

\<l<k 

y  :=  Vi </<t  y/ 

{y  =  x  6  U!<,<fc5;} 

Figure  4.12:  A  multiple-server  implementation  of  member  for  y  =  x  €  5. 
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{true} 

if  !!<,<*  true  -► 

{true} 

member j{x,y) 

{y  =>  x  €  Ui^KjfcSj} 

ft 

{y  =>  x  €  Ui</<tS/} 

Figure  4.13:  A  multiple- server  implementation  of  member  for  y  =>  x  €  S. 

In  order  to  make  (4.16)  valid,  we  must  replace  the  action  member  by  some  com¬ 
position  of  actions  member j.  To  design  this  replacement,  we  assume  that  the 
semantics  of  member  j  is  the  one  given  in  (4.14)  above.  It  is  straightforward  to 
observe  that  the  proof  outline 

{true} 

member j(x,y) 

{V  =  x  €  Sj} 

{y  =>  x  €  U i<j<iS/} 

is  valid.  This  proof  outline  leads  to  the  multiple-server  implementation  of  member 
that  is  given  in  Figure  4.13. 

Comparing  the  program  in  Figure  4.12  with  the  one  in  Figure  4.13  illustrates 
the  effect  that  a  specification  can  have  on  the  efficiency  of  its  implementations.  A 
designer  will  often  use  a  strong  requirement,  such  as  y  =  i  6  5,  simply  because 
a  single  server  happens  to  provide  it,  although  this  strong  requirement  is  not 
really  uaed.  When  implementing  a  specification  in  some  environment  where  the 
implementation  costs  for  the  strong  and  weak  specifications  differ  (e.g.,  multiple- 
server  implementations),  use  of  the  weak  specification  usually  has  advantages. 

Another  implementation  of  member  could  set  y  to  false.  Although  this  imple¬ 
mentation  is  obviously  not  desirable,  the  only  formal  way  of  preventing  such  an 
implementation  from  consideration  is  by  specifying  properties  involving  liveness 
as  well  as  safety. 
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Finally,  the  reader  might  have  noticed  that  the  derivation  of  the  multiple- 
server  implementation  of  the  monotonic-set  service  was  done  without  a  concrete 
context  of  clients.  In  Section  4.1,  where  we  developed  a  multiple-server  imple¬ 
mentation  of  a  mutual  exclusion  service,  the  client  context  was  explicit.  The 
client  context  is  necessary  for  arguing  validity.  Without  it,  one  does  not  have  the 
necessary  information  for  proving  interference  freedom.  In  other  words,  prov¬ 
ing  validity  of  PO(h(a)),  for  some  internal  action  a,  is  not  enough  to  establish 
validity  of  the  proof  outline  containing  PO(h(a)).  One  must  prove  that  asser¬ 
tions  in  PO(h(a ))  3X6  not  interfered  with  (by  other  actions  in  the  program  where 
PO(h(a))  is  inserted)  and  that  actions  of  PO(h(a))  do  not  interfere  with  asser¬ 
tions  outside  PO(h(a)).  In  general,  this  can  be  done  only  when  the  context — i.e., 
the  clients  programs — is  given  explicitly. 


•4 


> 


Chapter  5 


Conclusion 


In  this  thesis,  we  have  presented  a  new  approach  for  designing  distributed  ser¬ 
vices.  We  consider  a  multiple-server  implementation  of  a  service  to  be  correct  if 
it  implements  a  single-server  based  specification  of  the  service.  In  presenting  such 
a  specification,  one  must  distinguish  the  client  code,  which  may  not  be  changed 
in  different  implementations,  from  the  code  of  client  stubs  and  the  server,  which 
may  be  changed  by  implementations.  This  distinction  is  achieved  by  classifying 
the  server  and  stubs  as  internal  elements  of  the  specification  and  classifying  the 
other  parts  as  external  elements  of  the  specification.  Multiple-server  implemen¬ 
tations  are  derived  from  a  specification  by  rewriting  the  client  stubs  and  server 
programs,  using  several  servers  instead  of  one.  We  developed  the  theory  of  proof 
outlines  as  specifications  and  the  notion  of  structural  refinement,  to  support  this 
derivation  process. 

We  presented  a  methodology  for  deriving  multiple-server  implementations  of 
services  from  single-server  based  specifications  of  the  services.  Thus,  our  method¬ 
ology  decomposes  the  problem  of  designing  a  distributed  service  into  two  phases: 
a  single-server  phase,  during  which  a  single-server  implementation  of  the  service 
is  designed,  and  a  multiple-server  phase,  during  which  a  multiple-server  imple¬ 
mentation  of  the  single-server  based  specification  is  developed. 
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One  advantage  of  decomposing  the  design  process  in  this  manner  is  the  sep¬ 
aration  of  concerns  that  is  afforded.  In  the  first  phase,  one  addresses  only  the 
problems  inherent  in  implementing  the  service;  and  in  the  second  phase  one  ad¬ 
dresses  only  the  issues  of  associated  with  a  distributed  implementation.  Another 
advantage  of  our  two-phased  decomposition  is  that  a  designer  can  trace  prob¬ 
lems  in  a  multiple-server  implementation  (correctness  as  well  as  performance) 
to  the  single-server  design  or  to  the  refinement  mapping  or  to  choices  made  in 
implementing  internal  server  actions.  Without  separating  the  design  into  two 
phases,  it  is  not  clear  what  design  decisions  are  made  due  to  inherent  charac¬ 
teristics  of  the  clients/service  problem  and  what  design  decisions  are  due  to  the 
strategy  adopted  to  coordinate  servers.  For  example,  when  using  a  network  that 
does  not  deliver  requests  in  the  order  they  are  issued  by  the  clients,  certain  or¬ 
dering  constraints  on  clients  requests  may  have  to  be  enforced — evf»n  when  the 
service  is  implemented  by  a  single  server.  Thus,  ordering  constraints  required  by 
a  multiple- server  implementation  of  a  service  are  necessarily  the  conjunction  of 
ordering  requirements  inherent  in  the  service  and  ordering  requirements  needed 
for  server  coordination. 

Another  benefit  of  our  approach  over  other  approaches  for  implementing 
distributed  services  is  that  it  allows  use  of  different  servers  in  implementing  a 
service — we  only  require  that  the  semantics  of  individual  servers  will  allow  imple¬ 
menting  the  single-server  abstraction.  We  do  not  require  that  individual  servers 
be  exact  replicas  of  each  other. 

Finally,  we  should  point  out  that  viewing  proof  outlines  as  specifications  and 
the  concept  of  structural  refinement  are  not  limited  to  the  problem  of  designing 
multiple- server  implementations  of  services.  These  concepts  may  be  used  in  any 
design  method  that  is  based  on  step-wise  refinement. 


5.1  Relation  to  Other  Work 


The  idea  that  a  data  abstraction  and  its  implementations  are  related  by  a  map¬ 
ping  between  their  state  spaces,  can  be  traced  to  Hoare’s  paper  [Hoa72]  on  im¬ 
plementing  data  abstractions. 

Dijkstra  uses  the  notion  of  abstract  variables  in  deriving  programs  (see  [Dij76], 
Chapter  8).  There,  once  a  solution  in  terms  of  some  set  of  abstract  variables  is 
derived  and  proved  correct,  it  is  refined  by  expressing  the  abstract  variables  in 
terms  of  some  other,  less  abstract  ones.  Such  a  step  requires  replacing  statements 
that  use  the  abstract  variables  by  other  statements  that  manipulate  the  new  set 
of  less  abstract  variables. 

Gries  and  Prins  [GP85]  introduced  the  notion  of  a  representation  invariant 
\  formula  relating  implementation  states  to  abstract  states.  A  representation 
invariant  is  used  in  deriving  an  implementation  for  abstract  operations  from 
their  specification.  The  work  of  Feijen,  van  Gasteren,  and  Gries  [FvGG87]  also 
uses  representation  invariants.  In  [Pri87]  the  term  coupling  invariant,  which  was 
suggested  by  Feijen,  is  used  instead.  An  important  difference  between  [Hoa72] 
and  [GP85]  is  that  a  representation  invariant  characterizes  a  relation  between 
states  of  the  implementation  and  states  of  the  abstraction,  whereas  in  [Hoa72]  the 
relation  is  required  to  be  functional.  It  seems  that  by  adding  auxiliary  variables 
to  the  implementation  state  space  one  can  always  make  this  relation  functional. 

The  common  theme  of  the  works  mentioned  above  is  that  in  developing  a  pro¬ 
gram  to  satisfy  a  given  (input/output)  specification,  one  first  derives  an  abstract 
program  that  provably  satisfies  the  specification,  and  then,  by  using  a  mapping 
that  expresses  the  abstract  variables  in  terms  of  concrete  variables,1  one  refines 
the  abstract  program  to  get  a  concrete  one  that  satisfies  the  same  specification. 
Our  work  can  be  viewed  as  applying  these  ideas  in  the  context  of  concurrent  pro- 

'Abstract  and  concrete  are  relative.  Even  assembly  language  notation  is  quite  abstract  when 
one  considers  the  hardware  level  with  its  transistors,  wires,  and  clock  signals. 
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grams,  where  specifications  characterize  sequences  of  states  (or  actions)  rathei 
then  just  pairs  of  states.  Our  work  however,  is  explicit  in  specifying  the  abstract 
(we  use  the  term  internal)  and  concrete  ( external )  elements  of  the  state  space, 
and  restricts  transformations  to  the  internal  elements  only.  Also,  since  our  work 
allows  for  explicitly  defining  certain  actions  as  internal  (even  if  all  variables  ac¬ 
cessed  by  those  action  are  external),  it  supports  transformation  even  in  the  action 
space  alone. 

The  work  reported  in  this  thesis  was  not  done  as  an  extension  of  the  ideas 
in  [Dij76,GP85,Hoa72],  but  rather  as  an  attempt  of  using  the  notions  of  spec¬ 
ification  and  implementation  together  with  proof  outlines  to  aid  in  developing 
multiple-server  based  distributed  algorithms.  The  relationship  to  the  works  cited 
above  only  became  apparent  much  later.  We  believe  that  exposing  this  relation¬ 
ship  is  one  of  the  contributions  of  our  work. 

Carrol  Morgan  [Mor88]  also  tries  to  unify  the  notions  of  specification  and  im¬ 
plementation  (i.e.,  program).  In  Morgan’s  work,  a  pair  of  predicates  [p,  g]  defines 
a  specification  statement,  and  any  program  P  for  which  the  triple  {p}P{g}  is 
valid,  satisfies  (or  implements)  \p,q).  In  our  terminology,  a  specification  state¬ 
ment  [p,  7]  corresponds  to  a  triple 

{?}<«){?} 

where  a  has  been  classified  as  an  internal  action.  An  obvious  and  major  difference 
between  Morgan’s  work  and  ours  is  that  Morgan  addresses  sequential  programs, 
whereas  we  address  concurrent  programs. 

In  Unity  (CM88),  the  notion  of  design  by  refinement  is  forcefully  advocated. 
A  key  idea  in  the  Unity  approach  is  that  one  first  designs  a  solution  to  a  problem 
at  a  high  level  of  abstraction  and  later  maps  this  solution  to  various  architectures. 
In  principle,  the  mapped  versions  of  the  original  solution  all  solve  the  problem 
that  the  original  one  did.  However,  the  derivation  of  the  mapped  versions  is  not 
driven  by  a  refinement  mapping  (or  some  other  formal  kind  of  mapping).  Other 
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aspects  of  program  transformation  that  are  defined  in  Unity  are  the  notions  of 
composing  programs  by  union  and  by  superposition.  These  transformations  have 
the  property  that  the  transformed  program  satisfies  any  property  that  the  original 
one  did.  However,  these  transformations  do  not  provide  an  easy  (or  straightfor¬ 
ward)  method  for  replacing  abstract  (internal)  elements  of  the  original  program. 
Using  an  always  section,  one  might  express  relationship  between  abstract  and 
concrete  variables  but  the  union  and  superposition  transformations  provide  no 
way  of  replacing  abstract  actions  (those  that  manipulate  the  abstract  variables) 
by  concrete  ones.  It  seems  that  the  only  way  to  construct  a  concrete  program  is 
by  starting  with  a  program  in  equational  form  (i.e.,  no  assign  section)  and  then 
superposing  it  with  some  set  of  concrete  actions.  Also,  in  many  cases,  it  seems 
that  the  original  specification  must  be  changed  (or  augmented)  to  account  for 
the  details  of  the  superposed  program. 

Another  significant  approach  to  reasoning  at  several  levels  of  abstraction  is 
the  one  based  on  I/O  Automata  [LT87,LM86].  Components  of  a  system  can 
be  specified  as  I/O  automata,  and  several  automata  can  be  composed  to  form 
another  automaton.  Interaction  between  individual  automata  is  restricted  to  the 
sharing  of  input/output  actions,  input  actions  must  be  always  enabled,  and  the 
set  of  actions  is  partitioned  into  extemal/internal  ones — supporting  the  notion 
of  external  and  internal  elements  of  a  specification.  The  model  supports  a  form 
of  liveness  termed  “fair  executions”.  The  emphasis  of  the  I/O  automata  model, 
however,  is  not  on  program  derivations,  but  on  rigorous  a  posteriori  verification. 

On  tbe  more  practical  side  of  distributed  computing,  we  should  point  out  that 
the  body  of  work  on  the  state  machine  approach  on  one  hand  and  on  manag¬ 
ing  replication  on  the  other  (in  particular  [LL86]),  strongly  motivated  our  work. 
We  conjectured  that  although  the  algorithms  described  under  state  machine  ap¬ 
proach  look  different  from  the  ones  described  under,  say,  the  Highly  Ava.  „ble 
Distributed  Services  methodology  [LL86],  they  are  fundamentally  the  same.  More 
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specifically,  we  conjectured  that  the  bond  that  ties  these  seemingly  different  algo¬ 
rithms  together  is  implementing  a  single-server  abstraction.  The  state  machine 
approach  is  a  generic  method  for  developing  replicated  servers  that  implement  a 
single-server  abstraction,  whereas  the  other  replication  management  schemes  are 
application  dependent  methods  to  do  exactly  the  same.  We  hope  that  our  work 
establishes  the  validity  of  this  conjecture  and  provides  a  unifying  framework  for 
designing  distributed  clients/service  algorithms. 

Another  branch  of  research  in  the  area  of  managing  replication  that  we  like  to 
address  is  the  work  of  Frank  Schmuck  in  the  context  of  the  ISIS  project  at  Cor¬ 
nell  [Sch88j.  This  work  investigates  the  effect  of  ordering  constraints  on  the  kind 
of  server /clients  problem  that  can  be  solved  in  a  distributed  system.  In  contrast 
to  [Sch88],  the  methodology  presented  here  addresses  ordering  as  well  as  issues 
of  degree  of  multicasting  (i.e.,  how  many  server  instances  should  be  addressed 
for  a  certain  operation).  Thus,  in  our  methodology,  trade  offs  between  multicast 
degree  and  order  can  be  exploited.  In  addition,  the  methodology  presented  in 
this  thesis  does  not  restrict  servers  to  be  replicas  of  each  other. 

5.2  Future  Work 

This  thesis  provides  a  theory  for  reasoning  on  distributed  algorithms  of  the 
clients/service  type.  It  also  presents  a  methodology  for  designing  multiple- server 
implementations  of  services  that  is  based  on  this  theory.  This  work  can,  and 
should,  be  extended  in  several  directions: 

•  More  experience  with  using  the  theory  and  the  methodology  is  needed. 

•  Support  liveness  properties. 

•  Support  fault- tolerant  implementations. 

A  more  detailed  discussion  of  these  points  follows. 
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5.2.1  Experience 

At  the  initial  stages  of  the  research  that  lead  to  this  thesis,  we  have  developed 
a  distributed  deadlock  detection  algorithm.  This  was  done  in  the  spirit  of  our 
methodology  but  certainly  not  by  the  letter,  and  we  would  like  to  examine  and 
probably  redevelop  the  algorithm. 

Another  problem  we  would  like  to  address  is  the  design  of  a  multiple-server 
implementation  of  a  full-scale  set  service.  The  development  in  Chapter  4  serves 
only  to  demonstrate  some  basic  concepts.  We  would  like  to  include  a  delete 
operation  and  explore  other  options  for  refinement  mappings. 

Recently,  we  started  investigating  the  problem  of  refining  distributed  algo¬ 
rithms  that  tolerate  benign  type  of  failures,  such  as  crash  failures,  to  algorithms 
that  tolerate  more  severe  type  of  failures,  such  as  omission  or  even  arbitrary  fail¬ 
ures.  The  problem  and  solutions  were  presented  in  [NT88J.  Concepts  developed 
in  this  thesis  can  be  used  in  solving  this  problem,  and,  based  on  some  preliminary 
work,  we  believe  that  this  might  reveal  new  solutions. 

5.2.2  Liveness 

Liveness  properties  are  sets  of  behaviors  where  every  finite  prefix  of  a  behavior 
can  be  extended  such  that  the  resulting  behavior  is  in  the  property.  In  more 
intuitive  terms,  a  liveness  property  characterizes  executions  in  which  something 
“good”  actually  happens.  A  formal  discussion  of  safety  and  liveness  can  be  found 
in  [AS85]. 

The  work  in  this  thesis  addresses  only  safety  properties  and  should  be  ex¬ 
tended  to  address  liveness  as  well.  Without  liveness,  one  can  always  derive  trivial 
implementations — satisfy  the  safety  requirement  simply  by  doing  nothing.  Tech¬ 
nically,  liveness  is  added  to  a  specification  by  augmenting  the  behavior  axioms 
with  liveness  axioms.  Thus,  the  principles  presented  in  Chapter  2  hold  for  live¬ 
ness.  The  problem  is  how  a  theorem  like  Theorem  2  (implements)  should  be 
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changed,  if  at  all,  so  that  liveness  will  be  addressed. 

5.2.3  Failures 

The  issue  of  handling  faulty  servers  was  not  addressed  in  this  thesis.  Our  conjec¬ 
ture  is  that  it  can  be  addressed  by  designing  fault-tolerant  refinement  mappings. 
Such  a  mapping  is  robust  and  well-defined  even  if  a  certain  number  of  the  server 
instances  are  faulty.  If  we  consider  the  set  example  of  Chapter  4,  the  refinement 
mappings  in  (4.10)  and  (4.11)  are  defined  in  terms  of  the  states  of  all  server 
instances  and  thus  become  undefined  whenever  a  single  server  fails.  A  mapping 
that  is  based  on,  say,  a  majority  of  the  servers  is  more  robust. 

Note,  by  reducing  the  number  of  server  instances  needed  for  the  refinement 
mapping  to  be  defined,  one  increases  the  redundancy  of  information  stored  and 
thus  increases  the  degree  of  fault-tolerance.  However,  the  requirement  that  the 
mapping  must  be  well-defined  might  have  an  adverse  effect  on  performance  be¬ 
cause  updates  to  this  redundant  information  must  be  coordinated. 
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